[05:23] morning [06:11] xdg mime handling feels like a maze [06:46] PR snapd#6709 closed: release: 2.38.1 [06:49] mvo: hi [06:50] mvo: can you upload 2.38.1 source packages to the releases page? [06:55] Good morning [06:55] A bit sleepy today [06:56] I stayed way too long hacking on snap confine last night [07:00] zyga: hey [07:01] PR snapd#6661 closed: data/selinux, tests/main/selinux-clean: fine tune the policy, make sure that no denials are raised === pstolowski|afk is now known as pstolowski [07:05] morning [07:08] pstolowski: hey [07:08] zyga: btw. tried 19.04 with my gt1030 and did not run into any problems (at least with proprietary drivers) [07:14] PR snapd#6711 opened: tests/main/selinux-lxd: make sure LXD from snaps works cleanly with enforcing SELinux [07:18] PR snapd#6238 closed: [WIP] many: add minimal SELinux support, refactor the policy [07:19] #6692 is super simple and needs a 2nd review [07:19] PR #6692: interfaces: cleanup internal tool lookup in system-key [07:26] PR snapd#6707 closed: overlord: factor out mocking of device service and gadget w. prepare-device for registration tests [07:28] mborzecki: curious why it didn’t work for popey [07:29] zyga: do you know if there was a specific snap that failed for him? [07:30] No, I don’t recall [07:41] zyga: to be exact, there's 418 nvidia drivers installed on the host, my graphics-debug-tools-bboozzoo snap seems to work fine with core and core18 bases [07:41] hm maybe it's godot specific [07:42] zyga: fwiw godot is classic :/ [07:44] zyga: aand it doesn't work [07:50] mborzecki: hey, sorry for the delay, had a meeting [07:50] mborzecki: 2.38.1 is not really needed outside of ubuntu/debian, its only packaging changes [07:59] mborzecki: great, so it's consistent [07:59] mborzecki: so what did work and what did not work and what are the symptoms of not working? [08:00] man, it's cold today [08:00] zyga: confined snaps worked (core, core18), classic does not [08:00] mborzecki: that's most curious [08:01] mborzecki: if yo want to learn more please do, I'm going to keep pushing on bugfixes from last weeks [08:08] mborzecki: arguably [08:08] mborzecki: once we have the support for classic mount namespaces [08:08] mborzecki: we could enable driver support for classic snaps as well [08:20] * zyga is gardening email [08:54] hmmmmm [08:55] why do we update fc-cache twice in LinkSnap - before and after changing current symlink? [08:56] pstolowski: the after part is bc you may be updating from pre-fc-cache version of core/snapd [08:56] (the second is probably a no-op if fc-cache finds all the files in place) [08:57] pstolowski: the before part will make sure the cache was updated before the snap is runnable [08:58] mborzecki: ah, i see, the logic there is a bit subtle [09:10] * Chipaca is having a paperwork-y kind of day [09:38] Chipaca: we never did but at this point we could remove the code about AnonymousDownloadURL from store, right? [09:39] pedronis: we have AnonymousDownloadURL code? [09:39] Chipaca: we do [09:39] ah, AnonDownloadURL [09:48] Hi snappy people, I am not able to connect to kubernetes-support https://pastebin.ubuntu.com/p/ZhdT3gPvgD/ "Multiple definitions for hat systemd_run in profile (null) exist,bailing out." is the error. ANy hints? [09:54] kjackal: hey, looks like a bug in snapd [09:54] kjackal: can you please report it [09:55] Sure, seem like I cannot do two connections in the kubernetes support interface [09:56] can you tell me more how you got the two connections? [09:58] sure [09:58] let me push the yaml [10:00] pedronis: we'd have to check that in all cases the other url is populated though [10:01] zyga: Here are the two flavors of the kube-support interface https://github.com/ubuntu/microk8s/blob/feature/strict-v2/snapcraft.yaml#L21 [10:01] [10:01] The second connect is failing: [10:01] > sudo snap connect microk8s:k8s-kubeproxy :kubernetes-support [10:01] > sudo snap connect microk8s:k8s-kubelet :kubernetes-support [10:01] error: cannot perform the following tasks: [10:01] zyga: ^ [10:02] kjackal: the reason for the failure is as follows: [10:02] kjackal: the definitions are mutually exclusive [10:02] kjackal: the plug definitions at the top of the snap yaml are global [10:02] kjackal: if an app has no plugs or slots defined it gets access to *all* plugs and slots defined at the global level [10:03] kjackal: the ctr app is one example in your yaml [10:03] it will get access to docker-privileged, k8s-kubelet and k8s-kubeproxy [10:03] kjackal: snapd does not detect mutually exclusive plugs or slots from being connected [10:03] kjackal: apparmor parser detects the conflicting permissions granted and rejects the generated apparmor profile [10:04] kjackal: that is all [10:05] thank you zyga I will need some time to ingest exactly what you said, and I will get back to you [10:05] brb [10:06] kjackal: I encourage you to seek clarifications for any of the items I listed at any time [10:25] brb [10:57] cachio: hi, can we update fedora & centos images? [10:58] cachio: seems like there,s a bunch of pending updates that have not been applied yet [11:06] mborzecki: hi, yes, I just reviewed that because both have been updated but seems to be an error during the process [11:06] https://travis-ci.org/snapcore/spread-cron/builds/517200642#L2633 [11:06] I'll fix that and recreate the images [11:07] PR snapd#6712 opened: overlord/snapstate: add timings to critical task handlers and the backend [11:10] cachio: ah, so it's not related to fedora/centos running tests, but rather a problem with gcp project config [11:13] mborzecki: yes [11:14] It failed to create the image but the build is in green [11:14] I'll retrigger the image and poke this issue [11:17] spread does not build anymore, golang.org/x/net dropped the context package [11:17] niemeyer: hey, seems to be a permissons issue on gce, I wuold need this one https://paste.ubuntu.com/p/CHYvrgDnvC/ [11:24] mborzecki: we are not creating any image because a change in the permissions [11:24] mborzecki: we need gustavo for this [11:25] mborzecki: I am trying to workaround that untils we fix the permissons issue [11:35] mborzecki: thank you [11:40] PR snapd#6713 opened: tests/upgrade/basic: restore SELinux context of /var/cache/fontconfig [11:41] pstolowski: if you could ^^ [11:41] zyga: do you know of other classic snaps that may want to use opengl? [11:41] no [11:44] * pstolowski lunch [11:45] PR snapd#6714 opened: cmd/snap-confine: reject crafted /tmp/snap.$SNAP_NAME [11:46] * cachio afk [11:51] is it possible to set the value refresh.retain while packaging snapd and not just after it? === ricab is now known as ricab|lunch [11:57] mborzecki: godot uses locally embedded libGL.so [11:57] Girtablulu|Away: no, not at present [11:58] thanks for the answer [11:59] zyga: duh, why would they do that? [11:59] mborzecki: it's one of the problems with snapcraft and GL today [11:59] we need to change that across the ecosystem to fix the problem [12:00] ldd of godot https://www.irccloud.com/pastebin/0Y1v1Jfc/ [12:00] this is not sustainable: we cannot expect to support new hardware when everything is frozen like that [12:00] mborzecki: I'm thinking of several solutions, happy to discuss [12:00] mborzecki: one of those elements is to package a new shim gl library that snapcraft will use instead of the real libraries [12:01] the shim gl is just there to satisfy dependencies, it does not actually contain any gl system [12:01] at runtime it would always be supplied by snapd, even for things like mesa [12:01] the problem is that this is complex to execute [12:01] at the same time I don't see anything that doesn't involve fixing snaps [12:02] zyga (cc kjackal): I think you mispoke [12:03] oh? [12:03] zyga: the plugs at the top are only global if there are no plugs down below [12:03] not quite, if an app has zero plugs or slots defined, it does get all globally defined plugs and slots [12:03] I don't know if we have a way to say "I want none" [12:03] like plugs: [] [12:04] or if snapcraft would not remove that [12:04] "down below" I assume you mean at app level? [12:04] yes [12:04] also, I used the pasted snap.yaml and there were no issues [12:05] https://paste.ubuntu.com/p/sRcydgPNhb/ [12:05] hmmm [12:05] that's odd [12:05] zyga, kjackal: ^ [12:06] jdstrand: offtopic: https://github.com/snapcore/snapd/pull/6714 [12:06] PR #6714: cmd/snap-confine: reject crafted /tmp/snap.$SNAP_NAME [12:06] yes... it is failing over here... jdstrand how do you connect the two interfaces? [12:07] zyga: also, 'enable' has no plugs and it didn't get both interfaces. it got precisely 0 [12:07] hmm [12:07] * zyga checks stuff [12:07] zyga: so it is operating how I understand it, not how you described it [12:08] that code was changed a while ago to fix a related bug [12:08] perhaps there were some unexpected consequences or perhaps I just plain misremember how it is supposed to work [12:08] aha, I see [12:09] so a plug or slot defined at top level is only added to apps or hooks if it is not bound to any app or hook [12:09] that's actually sensible and less surprising [12:09] jdstrand: thank you for correcting me [12:09] kjackal: jdstrand is correct, my previous explanation is invalid [12:10] kjackal: https://paste.ubuntu.com/p/BpGjHgmfmj/ [12:10] jdstrand: I'm working on https://github.com/snapcore/snapd/compare/master...zyga:fix/suse-audit-4?expand=1 [12:10] jdstrand: I will add some spread tests for how this behaves before opening the PR though [12:10] jdstrand: then why am I getting this: https://pastebin.ubuntu.com/p/ZxTF2j4tyg/ [12:11] zyga: I'm going to pick daemon user today [12:11] jdstrand: on top of that I will add packaging changes to make the snapd socket and key executables owned and only executable by the new snapd group [12:11] pick? [12:11] Sorry I am very new to the strict confinement [12:11] jdstrand: one thing that I'm worried about, with regards to the snapd group, is that we have no stable GIDs across distributions [12:11] jdstrand: therefore it is unclear to me what should be placed in the core/snapd snaps [12:11] kjackal: what is the output of 'snap version' [12:11] jdstrand: perhaps, however ugly, that should be checked inside the snap* commands [12:12] jdstrand: http://paste.ubuntu.com/p/MdR8yPmzYc/ 2.38 [12:12] zyga: if you set daemon user aside, the concept as a whole is that snapd has a predictable mapping [12:12] (so they remain being root-owned and root-group-owned and executable by all but perform an explicit check at runtime) [12:12] zyga: let me rephrase, if you set system users aside, there is a predicatable mapping [12:12] jdstrand: I'm not sure I follow [12:14] zyga: it would take a lot to explain in irc. it is in the spec. I'll attempt to summarize. there are several types of these things. for 'shared-users' (aka 'global-ids' in the spec), the store maintains the uid/gid and username/group mappings so it is global across the ecosystem [12:14] zyga: same is true for private-users (aka private-ids) [12:15] jdstrand: perhaps I misunderstand how that answers one question: what is the GID of /usr/lib/snapd/snap-confine in the core snap [12:15] zyga: let me finish summarizing [12:16] zyga: with shared-users and private-users, they are prefixed with snap_ [12:16] zyga: so claim a uid/gid range that is high and create the users/groups everywhere predictably [12:17] jdstrand: hmmm [12:17] jdstrand: I see [12:17] initially I was assuming that the "snapd" GID would be < 1000 [12:17] zyga: for 'system-users' (aka system-global-ids) there is no snap_ prefix, so we can't guarantee that the username, group isn't taken [12:17] so a typical system gid value [12:17] jdstrand: so the new group would be snap_snapd? [12:17] with some high value? [12:18] so we would create these users on the fly if they don't exist, just like traditional packaging [12:18] then snapd does a lookup and injects the gid for that system into the policy [12:19] zyga: hold on [12:19] zyga: oh wait, this whole time you are talking about the setgid user [12:19] correct [12:19] zyga: I thought you were questioning the daemon user [12:19] ah, no [12:19] /o\ [12:19] sorry, maybe I was not clear about that [12:19] ok, please restate your concern [12:20] ok [12:20] * jdstrand flushes cache [12:20] given that the core snap is shared by all systems alike [12:20] the same applies to snapd snap [12:20] I was wondering what we should do about the value of GID on key executables like snap-confine and snap inside said snaps [12:20] my starting point was that I was trying to add a typical system group that has GID < 1000 [12:20] kjackal: can you unsquashfs the snap you are trying to install and paste the squashfs-root/meta/snap.yaml [12:20] but coordinating that in the ecosystem is hard [12:21] jdstrand: perhaps there's a better way, I just started thinking about this [12:22] zyga: ok right, that is likely a sisyphean task (trying to coordinate a low gid) [12:22] jdstrand, would you mind letting https://dashboard.snapcraft.io/snaps/smart-ad-demo/revisions/1/ pass ? (it is gone into manual review, being a kiosk daemon using the x11 plug/slot combo for xwayland) [12:22] zyga: I'm not even sure the line of demarcation (1000) can be depended upon everywhere [12:23] ogra: sure. I think I have an idea about how to fix that in the base declaration [12:23] lovely ! [12:23] jdstrand: perhaps the solution then is to not use the actual value [12:23] jdstrand: Here it is: http://paste.ubuntu.com/p/hTWhshW239/ (learning new tricks) [12:24] ogra: can you create a forum topic, then I can express my idea? [12:24] jdstrand: but instead query if the calling user is a member of the snapd group [12:24] whatever that value is [12:24] and then deny or allow [12:24] jdstrand, willcooke do [12:24] HAHA [12:24] *will do [12:24] :D [12:24] * willcooke does too [12:24] one tab too much [12:24] hehehe [12:24] * zyga notices a joke fly past him [12:25] that is probably the most humorous tab complete fail I've seen (at least in recent memory :) [12:25] :D [12:27] kjackal: that seems like a different snap.yaml from what you posted earlier [12:28] * jdstrand will examine it [12:28] zyga: yes, I think that is what you must do [12:28] jdstrand: thank you, I think, while unfortunate, it is unavoidable [12:29] hmm, mount-observe is not working? [12:29] https://paste.ubuntu.com/p/fpFsX36ZCb/ [12:29] zyga: ie, yoy make it build time configurable what group snap-confine will verify. then the packager ensure that group exists [12:29] jdstrand: how does that help? [12:29] zyga: it actually is ok. this is how lots of stuff works like this. eg, libvirt, lxd, docker, etc on their socket [12:29] I mean, are you aiming for names other than "snapd" [12:30] zyga: something like this: [12:30] ./configure --with-group=whatever [12:31] then for that build it is hardcoded to use 'whatever' [12:31] then the suse packager does 'addgroup whatever' [12:32] then it is all fine [12:32] right, I understand that [12:32] I'm seeing to understand why we want that to be configurable [12:32] I assume that "whatever" is a string, not an int [12:32] zyga: yes, precisely [12:32] not a string [12:32] ooh [12:32] hmmmm [12:33] so how does this help with the core snap [12:33] how will the shared snap-confine be configured? [12:33] of course, that only works with the non-rexec snap-confine [12:33] or are you saying that the shared one should not enforce this check? [12:33] I see now [12:33] hmm hmm [12:33] I would rather do something that works in both cases [12:33] you can [12:34] --with-group=snapd [12:34] but then you'd want to make it so that if the group doesn't exist, use old behavior [12:34] indeed [12:34] otherwise new. that is a little weird [12:35] also sometimes snap-confine starts on the inside of a mount namespace [12:35] so all a bit more complex [12:35] suse doesn't want re-exec anyway afaik [12:35] but yeah, I think that's workable [12:35] a first step might be just to support non-rexec using --with-user [12:35] yes, that's right, but I prefer to create features that don't impede global reexec as a _technical_ possiblity [12:35] zyga: /etc always comes through though [12:35] oh, /etc [12:36] how I hate that we did that [12:36] cause this is in /etc/group [12:36] we should have not done that and instead forge special /etc [12:36] in this case it is a good thing :) [12:36] I think we should explore /etc being an empty tmpfs managed with mount backend [12:36] it could ship symlinks for the 5-6 files we want [12:36] well, in this case it doesn't have to be a bad thing [12:36] (those would go to hostfs) [12:37] yes, I agree, it's just something that I recalled now that you mentioned it [12:37] (in context of the opencl test snap) [12:37] zyga: that's not going to work for people. there is a *ton* of stuff in /etc that snaps want. not least of which system-file [12:37] jdstrand: but the things in /etc are not consistent [12:38] I know what you are saying but we should work towards *predictable* and managed /etc [12:38] many things will need to alter what /etc contains [12:38] currently this is hard [12:38] and it is done so in a way that is not benefiting from snap-update-ns features [12:38] zyga: true, but that's life. people configure host certs, nss, users, groups, etc, etc, etc, etc [12:38] ssl certs don't work fully, it only works on ubuntu and debian AFAIK [12:39] anyway. I have other things to do. we can discuss something like that over a beer sometime [12:39] yeah :) [12:39] I think we're in agreement [12:39] and I think I broke gid restore somehow [12:39] * zyga debugs [12:39] jdstrand, for later ... https://forum.snapcraft.io/t/kiosk-apps-with-xwayland-kiosk-launch-needing-an-x11-slot-that-makes-them-go-into-manual-review/10892 [12:40] jdstrand: I see you are using a test-k8s, is there a repository for this? Is it a fork of microk8s? [12:42] kjackal: I just took the yaml you pasted and changed the name and the 'command' lines [12:42] it isn't a thing [12:43] I'm now looking at your unsquashed one [12:43] thanks [12:47] ogra: I did smart-ad-demo [12:48] thx ! [12:48] kjackal: I can't reproduce [12:49] kjackal: did you snap try or use a different snapd or anything else that might be relevant? [12:50] kjackal: can you perhaps try to install and connect everything in a clean vm? [12:50] I am doing a snapcraft cleanbuild on the branch I pasted above and then snap install ./microk8s_latest.snap --dangerous [12:50] kjackal: what does 'snap list microk8s' say? [12:52] jdstrand: http://paste.ubuntu.com/p/b4jKFyB2Y7/ [12:54] kjackal: please 'snap remove microk8s' then paste: ind /var/lib/snapd -name "*microk8s*" [12:54] jdstrand: I now see that the error I get is presents on any interface i am trying to connect https://pastebin.ubuntu.com/p/vVx8ZppVJX/ [12:54] s/ind/find/ [12:56] profile (null) for life [12:58] jdstrand: here is the find in /var/lib/snapd [12:58] https://pastebin.ubuntu.com/p/jTRkZYFPW2/ [12:59] PR snapd#6715 opened: interfaces/builtin/desktop: fonconfig v6/v7 cache handling on Fedora <⛔ Blocked> [12:59] https://pastebin.ubuntu.com/p/3ggcdDVFvq/ [12:59] kjackal: ok, good. now install and do the snap connects one by one until you see the first error, then show me that series of commands [13:02] jdstrand: Here it is https://pastebin.ubuntu.com/p/wgg7qsfyJq/ [13:04] kjackal: can you paste /var/lib/snapd/apparmor/profiles/snap.microk8s.daemon-kubelet [13:05] Hi! Is there a way to manually put snapd in the status that triggers https://bugs.launchpad.net/ubuntu/+source/gnome-initial-setup/+bug/1824188 ? [13:05] Bug #1824188: Software tab is empty on clean 19.04 install

[13:05] jdstrand: here it is http://paste.ubuntu.com/p/VMVTNpm4CW/ [13:05] otherwise debugging a fix is a mess [13:06] kjackal: ok, the profile looks ok. let me try to parse that in different place. gimme a minute [13:07] kjackal: this is just a standard bionic system. not in a container or anything? [13:07] no, that is my 18.04 laptop [13:08] I have a Vm on aws running if you want me to try [13:09] no [13:11] PR snapcraft#2526 closed: Release changelog for 3.4 [13:18] kjackal: ok, please remove microk8s, then install, then do: [13:18] sudo snap connect microk8s:k8s-kubeproxy :kubernetes-support [13:19] then: /var/lib/snapd/apparmor/profiles/snap.microk8s.daemon-kubelet /tmp/before [13:19] sudo snap connect microk8s:k8s-kubelet :kubernetes-support [13:19] then: [13:19] cp /var/lib/snapd/apparmor/profiles/snap.microk8s.daemon-kubelet /tmp/after [13:19] kjackal: I missed the 'cp' in the 'before' [13:21] trying it now === ricab|lunch is now known as ricab [13:22] kjackal: fyi, I can't reproduce in my bionic vm either [13:22] kjackal: once you have before and after, please paste: diff -Naur /tmp/before /tmp/after [13:26] Yes I understand jdstrand, no worries. I might have something wron on my system. Here is the diff: https://pastebin.ubuntu.com/p/TXpxKVm9X4/ [13:27] kjackal: ok, can you paste both before and after? [13:28] jdstrand: Here is the before: http://paste.ubuntu.com/p/qqcFm9Zxqk/ [13:29] jdstrand: here is the after: http://paste.ubuntu.com/p/HZFTPFmxk5/ [13:29] ok [13:29] the profile looks fine [13:30] can you make the snap available to me? perhaps via wormhole? [13:30] (snap install wormhole ; wormhole send /path/to/thing) [13:30] kyrofa / jdstrand : I'd like to use MySQL in a snap and found https://kyrofa.com/posts/snapping-nextcloud-mysql incredibly helpful (thanks kyrofa!) Just before I start adapting the conf files and pull all the customizations + patches in my snap: Is it still the case that snapd prevents setpriority calls, or does process-control (https://github.com/snapcore/snapd/blob/da75b241f517d11d38f620e1d71a899e36f2c037/interfaces/builtin/process_control. [13:30] go#L50) work for this? [13:31] kjackal: if using wormhole, privmsg me the code [13:32] dot-tobias: by default a snap may setpriority to >= 0 [13:32] dot-tobias: if it tries < 0, the call is denied but the application is not killed or anything [13:32] dot-tobias: process-control allows for < 0 [13:34] kjackal: ok, downloading. it'll be ~10 minutes [13:36] kjackal: while we are waiting, what is 'apt-cache policy apparmor' [13:36] jdstrand: so a question - if there's no explicit slot configuration, a snap will allow any autoconnection from same-publisher snaps. But if there's explicit "allow-auto-connection" configuration, then it will only allow the explicit ones and deny anything else, even from same publisher. Does this sound correct? [13:37] roadmr: it depends on the interface. that is how content is setup, yes [13:37] jdstrand: yes, the interface in question is content [13:38] roadmr: if the snap decl says anything about the constraint (in this case auto-connection), only the snap declaration is used. there is no merging or falling back to the base decl [13:38] jdstrand: Here is the apt apparmor policy http://paste.ubuntu.com/p/6dkCJmxNgf/ [13:39] jdstrand: ah, got it - that explains it very clearly [13:39] jdstrand: Ok, thanks. So for me (with next-to-none knowledge about this) this means that mysql-server should work OOTB without the patch that kyrofa applies for the Nextcloud snap: https://github.com/kyrofa/mysql-server/commit/dd0e4e497794da2650536097655f4bf732b261a9 (you added the process-control ~ 1 month after kyrofa's blog post which stated that there is no suitable interface for setpriority calls – or did snapd's behavior change from [13:39] kill to a mere denial?) [13:39] roadmr: it is very easy to get the content stuff wrong. perhaps privmsg me and describe what you are trying to do? [13:39] jdstrand: so this snap has 10 content interface slots, we added config for 4 of them which a cross-pub snap needs; and of course per the above,it means in order to allow same-publisher snaps to auto-conn to the other 6 interfaces I'll need to add those explicitly too, even though they weren't needed before [13:40] jdstrand: sure! I'll hit you in a sec [13:41] sorry we make things so tricky :) [13:41] dot-tobias: I don't have the dates at hand, but yes we changed from kill to just EPERM. whether mysql works depends on how it handles the error condition [13:59] mvo: cachio: this one I reviewed a while ago, it just needs some tweaks: https://github.com/snapcore/snapd/pull/6594 [13:59] PR #6594: [RFC] tests: run smoke tests on (almost) pristine systems [14:02] pedronis: sure, I'll take a look, thanks [14:03] PR snapd#6716 opened: store: serialize the acquisition of device sessions [14:10] heh, so i could not build spread, because context was removed from my tree of golang.org/x/net :/ [14:12] kjackal: ok, with your snap in a vm, I am able to reproduce [14:12] PR snapd#6643 closed: tests: deny ioctl - TIOCSTI with garbage in high bits [14:13] jdstrand: I will not be surprised if its something wrong I am doing [14:14] I'm not convined it is you [14:14] but now I can debug [14:15] the hooks [14:15]