[00:25] PR snapcraft#2878 closed: extensions: fix merging of build-environment [00:25] everyday less channels interesting here [00:25] after an uodate from 28.8bps modem to a 5Mbps fiber t1 Line [00:25] its sad [00:26] at least #snappy doesnt have trolls thank god [00:27] well too late for chat today, maybe i'll create a project called aspies/will/be/ddosed [00:27] ciao and thanks [00:45] ijohnson: yes, thanks! https://github.com/travis-ci/dpl/pull/1154 [00:45] PR travis-ci/dpl#1154: Update snapd [06:41] morning === Girtablulu_ is now known as Girtablulu [08:14] almost te [08:14] re [08:14] outside is lovely today [08:14] pstolowski: how does it look like outside for you? [08:18] zyga: hey, chilly (-1C) but sunny [08:29] zyga: pstolowski: -1 here too, mornig frost everwhere, yesteday evening was -3 and super foggy (no surprise though, +10 during the day) [08:36] re [08:36] -2 here when I woke up [08:36] and fog thick like cream [08:36] https://usercontent.irccloud-cdn.com/file/Phm3QnMj/image.png [08:37] when I finally got out to take Bit for a walk it was clearing [08:37] but still foggy [08:37] last night I read a little about table layout problem [08:37] and I decided not to :) [08:37] at least not during work hours [08:37] it's a significant chunk of work [08:37] today I'll start with selinux [08:39] good morning :) [08:39] what is table layout problem ? [08:39] sdhd-sascha: you have a table comprised of cells [08:39] zyga: what about selinux? [08:39] sdhd-sascha: some cells may span several rows or columns [08:39] sdhd-sascha: each cell has text inside [08:40] sdhd-sascha: text can wrapped according to typical rules (e.g. break on spaces) [08:40] sdhd-sascha: the problem is [08:40] sdhd-sascha: given set width [08:40] sdhd-sascha: compute the minimum height of the table [08:40] sdhd-sascha: this is NP complete [08:40] sdhd-sascha: then you have more constraints, e.g. to make text look good according to some optimization function [08:40] sdhd-sascha: there are some heuristics to follow (that all the implementations use) [08:41] ah, ok, cool [08:41] sdhd-sascha: there are perfect solutions using very expensive algorithms, mainly to measure the speed and quality of a given heuristic [08:41] sounds like perfect for functional programming and recursion [08:41] sdhd-sascha: but they all involve heavy math and optimization problems [08:41] sdhd-sascha: linear algebra, dynamic programming [08:42] sdhd-sascha: not "I'll write this after reading a paper" in one evening [08:42] sdhd-sascha: the problem of figuring out how to size a cell is called cell configuration [08:43] sdhd-sascha: and each cell has a finite set of configurations [08:43] sdhd-sascha: typically one is best but it's quadratic or O(N^2/3) at best with tricks to find cell configuration that's good [08:43] sdhd-sascha: that's per cell with N being word legth [08:43] *count [08:43] sdhd-sascha: anyway [08:43] sdhd-sascha: it's fun but not for work [08:44] zyga: maybe, find the cell with the least possibilities. Then call the next, with least possibilities... Could be a starting point [08:45] zyga: yes, that's really fun :-) And true, it needs time [08:45] This problem has been researched since 1960s [08:45] There are lots of good algorithms but they are all complex to implement [08:45] 1960s - hmm, sounds like functional programming [08:46] it's sure a compination of bread first and deep first searches [08:46] combination - (sorry) [08:47] https://people.eng.unimelb.edu.au/gkgange/pubs/table_11.pdf [08:48] and, sorry not "bread" - i mean breadth-first [08:48] cool - thank you :-) [08:50] zyga: hmm - because of the symlink not possible problem in snap. I will give the user at first a setup.sh script like alan it does. [08:50] Maybe i can set an alias after the first start from setup-script to real-app. [08:54] we should discuss the problem [08:54] and come up with a strategy to fix it [08:55] pstolowski: I have a selinux denial to fix in my pR [08:57] ic [09:07] zyga: while updating one of my PRs related to portal support, I noticed that a test I'd added was failing on Fedora 31 due to it using cgroups v2. Is that something that is likely to be fixable? [09:08] jamesh: can you be more specific please? [09:08] jamesh: I have this for cgroupv2 https://github.com/snapcore/snapd/pull/7825 [09:08] PR #7825: many: use transient scope for tracking apps and hooks [09:08] jamesh: but it needs another review [09:08] it's open since november [09:08] zyga: it was code using this snapFromPid() code: https://github.com/snapcore/snapd/blob/master/usersession/userd/helpers.go#L76 [09:08] jamesh: ah, yes [09:09] which has a "if cgroup.IsUnified()" error case at the top [09:09] jamesh: I need to look but I think can be fixed [09:09] jamesh: we have some generic code in sandbox/cgroup [09:09] jamesh: so I think the answer is "yes" [09:10] jamesh: it literally needs reviews and nothing else I think [09:10] zyga: I'm mainly concerned because I'd like to reimplement a quick "is this a snap?" check for xdg-desktop-portal itself (to replace the one relying on AppArmor) [09:10] yeah I remebmer that [09:10] I think mvo is trying to get reviews to work better [09:10] specifically security reviews [09:11] and if the freezer cgroup thing can't be relied on in the snapd code, then I probably shouldn't be writing more code that uses that method [09:11] it cannot be relied on [09:11] I remember at one point you'd talked about having some kind of marker file in the snap's mount namespace [09:12] jamesh: yes, we explored many ideas [09:12] jamesh: right now I cannot promise you the inode idea gets implemented [09:12] jamesh: but the cgroup idea is very close and seems to be entirely generic as well [09:12] jamesh: and all you need is one read() call to see which snap a process belongs to [09:14] but it'd be a different check compared to what that function is currently doing? [09:14] jamesh: yes [09:15] jamesh: the PR I referenced changes most (need to see if it changes userd code, I wasn't aware it does this) [09:16] zyga: I was looking at moving that utility function out of userd, so it could be used by the "snap routine portal-info" command [09:16] but it is still essentially the same code [09:16] yeah I think it should move to sandbox [09:16] mainly because it's one implementation over many [09:21] jamesh: FYI I will land https://github.com/snapcore/snapd/pull/7238 [09:21] PR #7238: usersession: add systemd user instance service control to user session agent

[09:21] jamesh: as soon as it goes green [09:21] jamesh: oh, and I have a question for you [09:21] zyga: thanks [09:22] jamesh: is https://github.com/snapcore/snapd/pull/7589 ok? [09:22] jamesh: Samuele asked you to changed the PR description [09:22] PR #7589: cmd/snap: add ability to register "snap routine" commands [09:22] but I wasn't following the history and not sure if you did or not [09:22] jamesh: can you comment there please [09:23] zyga: yep. The initial comment was edited as requested. [09:23] excellent [09:24] I'll merge it as well [09:24] I'll just merge master into it to ensure it's green still [09:25] zyga: out of interest, where in the sandbox package do you think that snapFromPid() function would best belong? [09:26] jamesh: sandbox/cgroup as it models the source of that information [09:27] okay. I was just wondering since the API is not particularly cgroup specific [09:28] it currently uses cgroups, but that seems like an implementation detail [09:33] jamesh: yeah but that's how the sandbox package is modeled now, if it changes we can just adjust the calling code; I think it's more important to have one implementation than an abstract entry point [09:33] (we can have both eventually) [09:33] fair enough [09:51] mborzecki: I cannot understand that selinux denial at all, looking at selinux policy now [09:51] zyga: got the avc log? [09:51] mborzecki: same as before but that's not the point [09:51] mborzecki: the denial is new [09:51] mborzecki: the denial comes from snap-discard-ns [09:51] mborzecki: using setegid [09:51] mborzecki: which it starts to in this PR [09:52] mborzecki: the point is - how can this be denied when it runs as root and snap-confine can setegid all it wants [09:52] and it calls setegid just prior to the fork/exec call [09:52] mborzecki: I must be missing something :/ [09:53] zyga: can you paste that denial? con't find it in history [09:53] sure, one sec [09:53] PR snapcraft#2882 closed: extensions: change extension merge-strategy to fix build-environment [09:53] type=AVC msg=audit(01/16/20 18:15:29.361:1557) : avc: denied { setgid } for pid=13356 comm=snap-discard-ns capability=setgid scontext=system_u:system_r:snappy_mount_t:s0 tcontext=system_u:system_r:snappy_mount_t:s0 tclass=capability permissive=1 [09:54] * Chipaca prepping for the trip [09:55] mborzecki: mvo: hi, #7992 needs 2nd reviews and some tweaks (see my own review comments) [09:55] PR #7992: bootloader: add ExtractedRunKernelImageBootloader interface, implement in grub [09:55] pedronis: i can take care of the tweaks [09:56] mborzecki: thx, please double check that my suggestions make sense [09:56] pedronis: ok [09:59] PR snapcraft#2847 closed: Catkin plugin: consider only 'local' workspaces [10:00] zyga: hm does s-d-n explicitly setgid? [10:00] mborzecki: yes, but it runs as root at that time [10:01] zyga: that's the point of selinux, even though it runs as root, the policy is in effect [10:01] mborzecki: snap-confine doesn't run with egid=0 [10:01] so it switches to egid=0 and back all the time [10:01] ? [10:01] sure [10:01] but [10:01] mvo: open PRs have grown quite a bit again :/ [10:02] why nothing for snap-confine [10:02] is it a separate policy? [10:02] pedronis: yeah, today is a busy day for me but I will try to do some more reviews [10:02] zyga: s-c already has setgid [10:02] ahhh [10:02] zyga: so selinux policy can actually confine root ;) [10:03] sure [10:03] I assumed that snap-confine policy would apply to snap-update-ns invoked from snap-confine [10:03] not that it would have a standalone policy [10:03] zyga: my first impulse feeling on #8008 is that is too big [10:03] PR #8008: render: add the render package and basic widgets [10:03] zyga: no, s-u-n and s-d-n are run with snappy_mount_t context which has a separate policy [10:05] Hey guys! Is there any timeline/progress on RPi4 support for Ubuntu Core? :D Curious, as we don't want to be stuck on RPi3 if I start building using Core now [10:06] zyga: i see there's an entry with `allow snappy_mount_t self:capability {..}`, add setgid there [10:07] pedronis: looking at how o/auth handles user addition and removal, don't we need a graveyard for users? [10:07] pedronis: if you don't know offhand i can dig myself :) [10:07] mborzecki: I see snappy_mount_exec_t [10:07] is that the type? [10:08] Chipaca: I'm not even sure I understand the question tbh [10:08] mborzecki: I don't see where it gets any permissions yet [10:08] pedronis: you know how we do refreshes bunched by user id [10:08] zyga: nope, snappy_mount_t, around like 426 in snappy.te [10:08] Chipaca: yes [10:08] pedronis: when a user logs out, we delete the user completely [10:08] pedronis: if they then log back in they get a new id [10:09] mborzecki: how is snappy_mount_t related to snap-discard-ns? [10:09] zyga: https://paste.ubuntu.com/p/P4q7VYpMh7/ [10:09] unless i'm missing something, that means the refreshes will be wrong? [10:09] as in, they'll be done as root from there on [10:09] Chipaca: aren't the ids always growing [10:09] pedronis: yes [10:09] we don't recycle ids, or do we [10:09] pedronis: no we don't [10:10] Chipaca: well, the refreshes will already be not working once they log otu [10:10] pedronis: but shouldn't they work again once they log back in [10:10] mborzecki: but how is that related? [10:10] *related [10:10] Chipaca: maybe yes [10:11] pedronis: i know this sounds related to my current work but it's actually because i resucitated an old laptop and the macaroon had expired so i logged out and back in and that got me thinking [10:11] zyga: both do stuff with mounts, so instead of making it even more fine grained both get the snappy_mount_t policy [10:11] Chipaca: you basically are saying that we should reuse the id if matching email [10:11] or something [10:11] I mean how is snap-discard-ns associated with snappy_mount_t [10:11] pedronis: meaning we should keep a graveyard of sorts to remember those things [10:11] zyga: how does selinux figure that out? [10:12] Chipaca: what happens if you don't logout but login again? [10:12] my point is that I cannot trace anything from snap-discard-ns [10:12] do we error? [10:12] to that place where you say to patch things [10:12] or do something else? [10:12] or it's a nop [10:12] (I don't remember myself) [10:13] zyga: quick HO? [10:13] mborzecki: how are those entries connected [10:13] mborzecki: sure [10:14] pedronis: looks like you get new macaroni [10:14] pedronis: it works [10:14] pedronis: (so yes i should've done that) [10:14] Chipaca: ok, so we have an issue but is not as bad as it could be [10:14] pedronis: yep [10:14] well, the error could be better [10:15] you just get an opaque 'invalid credentials' [10:15] but not clear we can improve on that easily [10:15] Chipaca: we need to think a bit, can you create a bug or something [10:15] to remember this [10:16] yes [10:16] thx [10:23] pedronis: https://bugs.launchpad.net/snapd/+bug/1860102 [10:23] Bug #1860102: snap logout and snap login with same account creates new user [10:23] Chipaca: thanks, tracking as mine for now [10:23] pedronis: 👍 [10:24] * Chipaca goes back to laptop resuscitation [10:27] PR snapd#7238 closed: usersession: add systemd user instance service control to user session agent

=== pedronis_ is now known as pedronis [10:27] jamesh: hi, could you add the comment jdstrand asked for in #7555, then it could be merged [10:27] PR #7555: tests: add a test demonstrating that snaps can't access the session agent socket [10:29] good luck Chipaca [10:31] https://github.com/snapcore/snapd/pull/8013 needs 2nd review [10:31] PR #8013: cmd/snap-bootstrap: check device size before boostrapping and produce a meaningful error [10:31] * zyga looks [10:33] mborzecki: is https://github.com/snapcore/snapd/pull/8013/files#diff-01caa2f676929e8131f31685ae61203cR216 a separate error that is fixed in this branch? [10:33] PR #8013: cmd/snap-bootstrap: check device size before boostrapping and produce a meaningful error [10:34] zyga: yes, separate patch in that branch [10:34] mborzecki: I have a small comment on the size code [10:37] PR snapd#7366 closed: interfaces/gpg-keys: Allow access to gpg-agent and creation of lockfiles [10:44] PR snapcraft#2883 opened: docker: add core18 snap that snapcraft now uses as a base [10:46] Can i anything do, for #7927 ? I still need a patched `snapd` to start sway on classic ubuntu. [10:46] PR #7927: interfaces: x11 allow apparmor on classic [10:47] sdhd-sascha: is not green atm, and needs a jdstrand review (he is off this week) [10:48] pedronis: ok, i rebase it to current master [10:49] mborzecki: I opened https://github.com/snapcore/snapd/pull/7980 for review now - the SELinux denial is gone [10:49] PR #7980: packaging,snap-confine: stop being setgid root [11:17] * Chipaca brb [11:19] PR snapd#8017 closed: tests: add ubuntu 20.04 to the tests execution and remove tumbleweed from unstable [11:21] Hi, as you know, i never worked with golang before. Is there a way to reset the source to a clean working state ? I deleted snapd/cmd/VERSION. And it's in `.gitignore`. So i wonder, how to reset without `go get ...` [11:24] PR snapd#8012 closed: o/devicestate: do not create perfTimings if not needed inside ensureSeed/Operational [11:24] sdhd-sascha: reset the git working dir of a project? 'git clean -xfd', beware it will forcefully remove any uncommited stuff in the working tree without asking [11:26] PR snapd#8006 closed: tests: skip interfaces-network-manager on arm devices [11:27] pstolowski: thank you. I found mkversion.sh. But it's confusing if you change the branch and then the version remains nearly the same. [11:27] I build 2.43 and wonder, why it still reports 2.42 ... [11:28] mborzecki: :) https://github.com/snapcore/snapd/pull/8016 [11:28] PR #8016: gitignore: ignore snap files [11:30] PR snapd#8016 closed: gitignore: ignore snap files [11:41] pedronis__: does your blocked label mean that no progress can be done on the render branch for the next week? [11:42] * zyga jumps into https://github.com/snapcore/snapd/pull/7614 [11:42] PR #7614: cmd/snap-confine: implement snap-device-helper internally [11:47] Hey, i read a lot of MAAS snap here. Is it in the store ? Or did i need to build it myself? [11:48] sdhd-sascha: I think it's unlisted until default tracks work, as upgrades from latest to 2.7 are painful [11:49] sdhd-sascha: but if you find sparkiegeek they might know more [11:49] (default tracks should be working on edge! woop woop) [11:53] Chipaca: thank you. I'm already on 2.7 on local installation and want to migrate to snap. [11:54] sdhd-sascha: note the versions in 'snap info maas' [11:55] hmm, i found it. thank you :) [11:56] Chipaca: did you know if there is a maas-rack and/or maas-region snap ? Or is it all-in-one ? If you didn't know. Then i will figure it out. No stress ;-) [11:56] sdhd-sascha: I don't know either :) I know next to nothing about maas in fact [11:58] Chipaca: I am also at the experimental level. would like to use maas with lxd and juju. [11:59] sdhd-sascha: #maas, maybe? (dunno) === pedronis__ is now known as pedronis [12:08] Chipaca: I think #7589 could land once green, can you quickly double check it again [12:08] PR #7589: cmd/snap: add ability to register "snap routine" commands [12:33] * zyga looks at another PR [12:35] PR snapd#7623 closed: tests: check world-writable and test-owned files [12:35] mborzecki, hello [12:35] I am reviewing a failing test [12:35] selinux-clear which is failing on centos [12:36] mborzecki, this is the error https://paste.ubuntu.com/p/5DxBHnD93d/ [12:36] seems to be real [12:38] cachio: hah, yeah, known problem, i'll update the policy, keeping centos in unstable systems doesn't help with catching issues like this one early [12:38] mborzecki, nice, thanks for the confirmation [12:49] cachio: updated #7871, thanks for pointing out pkgdb [12:49] PR #7871: tests: add spread test for hook permissions [12:49] pstolowski, yaw [12:54] PR snapd#7875 closed: interfaces: refactor path() from raw-volume into utils with comments for old [12:57] mborzecki: am I misreading or #7845 should be closed ? [12:57] PR #7845: cmd: add prefix to SYSTEMD_SYSTEM_GENERATOR_DIR [12:58] pedronis: IMO yes, the problem should be addressed in systemd (if ever) [12:59] ok [13:00] PR snapd#7845 closed: cmd: add prefix to SYSTEMD_SYSTEM_GENERATOR_DIR [13:03] added a note to 7845 with some suggestions on hot to approach this sdhd-sascha, it'd be nice to hear what upstream systemd suggest to use there [13:06] * sdhd-sascha I'm back later. And look [13:10] pedronis: agreed, 7589 can land once green [13:11] pedronis: can we land #7934, and potentially address ijohnson's suggestion re test refactor in a followup? [13:11] PR #7934: o/ifacestate,o/devicestatate: merge gadget-connect logic into auto-connect [13:13] pstolowski: yes, I suspect it would be good to fix the misleading comment though [13:15] pstolowski: I'm taking care of that [13:15] pedronis: ty [13:18] pstolowski: done, let's see if it gets green again [13:20] pedronis: btw, did you see https://forum.snapcraft.io/t/snapctl-changing-channel-ability/14900?u=chipaca ? [13:20] Chipaca: yes, I don't think is something we want to let snap do [13:20] in general [13:20] pedronis: right, not like that, but then they ask for more nuanced things in https://forum.snapcraft.io/t/snapctl-changing-channel-ability/14900/3?u=chipaca [13:21] some of them we already wanted (were already implementing?) [13:21] i mean, the 'are there updates in the current channel' one i thought was roadmapped even [13:21] yes [13:22] even refresh it's probably doable with some user confirmation [13:22] pedronis: 'reading current channel' seems a'ight, also [13:22] changing channel likely not [13:22] brb [13:22] agreed, not without some way of asking the user [13:29] https://github.com/snapcore/snapd/pull/8005 needs a 2nd review [13:29] PR #8005: api: don't return connections referring to non-existing plugs/slots [13:29] looking [13:31] Chipaca: answered or tried to [13:31] pedronis: some from → some form [13:31] :) [13:31] Chipaca: yea, fixed [13:31] already [13:32] pedronis: having to check version info to know channel breaks QAing a snap along channels though [13:33] Chipaca: I don't know, there is a list of features there, not use cases [13:33]