mborzeckixdg mime handling feels like a maze06:11
mupPR snapd#6709 closed: release: 2.38.1 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6709>06:46
mborzeckimvo: hi06:49
mborzeckimvo: can you upload 2.38.1 source packages to the releases page?06:50
zygaGood morning06:55
zygaA bit sleepy today06:55
zygaI stayed way too long hacking on snap confine last night06:56
mborzeckizyga: hey07:00
mupPR snapd#6661 closed: data/selinux, tests/main/selinux-clean: fine tune the policy, make sure that no denials are raised <SELinux> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6661>07:01
=== pstolowski|afk is now known as pstolowski
mborzeckipstolowski: hey07:08
mborzeckizyga: btw. tried 19.04 with my gt1030 and did not run into any problems (at least with proprietary drivers)07:08
mupPR snapd#6711 opened: tests/main/selinux-lxd: make sure LXD from snaps works cleanly with enforcing SELinux <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6711>07:14
mupPR snapd#6238 closed: [WIP] many: add minimal SELinux support, refactor the policy <SELinux> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/6238>07:18
mborzecki#6692 is super simple and needs a 2nd review07:19
mupPR #6692: interfaces: cleanup internal tool lookup in system-key <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6692>07:19
mupPR snapd#6707 closed: overlord: factor out mocking of device service and gadget w. prepare-device for registration tests  <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6707>07:26
zygamborzecki: curious why it didn’t work for popey07:28
mborzeckizyga: do you know if there was a specific snap that failed for him?07:29
zygaNo, I don’t recall07:30
mborzeckizyga: 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 bases07:41
mborzeckihm maybe it's godot specific07:41
mborzeckizyga: fwiw godot is classic :/07:42
mborzeckizyga: aand it doesn't work07:44
mvomborzecki: hey, sorry for the delay, had a meeting07:50
mvomborzecki: 2.38.1 is not really needed outside of ubuntu/debian, its only packaging changes07:50
zygamborzecki: great, so it's consistent07:59
zygamborzecki: so what did work and what did not work and what are the symptoms of not working?07:59
zygaman, it's cold today08:00
mborzeckizyga: confined snaps worked (core, core18), classic does not08:00
zygamborzecki: that's most curious08:00
zygamborzecki: if yo want to learn more please do, I'm going to keep pushing on bugfixes from last weeks08:01
zygamborzecki: arguably08:08
zygamborzecki: once we have the support for classic mount namespaces08:08
zygamborzecki: we could enable driver support for classic snaps as well08:08
* zyga is gardening email08:20
pstolowskiwhy do we update fc-cache twice in LinkSnap - before and after changing current symlink?08:55
mborzeckipstolowski: the after part is bc you may be updating from pre-fc-cache version of core/snapd08:56
pstolowski(the second is probably a no-op if fc-cache finds all the files in place)08:56
mborzeckipstolowski: the before part will make sure the cache was updated before the snap is runnable08:57
pstolowskimborzecki: ah, i see, the logic there is a bit subtle08:58
* Chipaca is having a paperwork-y kind of day09:10
pedronisChipaca: we never did but at this point we could remove the code about AnonymousDownloadURL from store, right?09:38
Chipacapedronis: we have AnonymousDownloadURL code?09:39
pedronisChipaca: we do09:39
Chipacaah, AnonDownloadURL09:39
kjackalHi 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:48
zygakjackal: hey, looks like a bug in snapd09:54
zygakjackal: can you please report it09:54
kjackalSure, seem like I cannot do two connections in the kubernetes support interface09:55
zygacan you tell me more how you got the two connections?09:56
kjackallet me push the yaml09:58
Chipacapedronis: we'd have to check that in all cases the other url is populated though10:00
kjackalzyga: Here are the two flavors of the kube-support interface https://github.com/ubuntu/microk8s/blob/feature/strict-v2/snapcraft.yaml#L2110:01
kjackal 10:01
kjackalThe second connect is failing:10:01
kjackal> sudo snap connect microk8s:k8s-kubeproxy  :kubernetes-support10:01
kjackal > sudo snap connect microk8s:k8s-kubelet :kubernetes-support10:01
kjackalerror: cannot perform the following tasks:10:01
kjackalzyga: ^10:01
zygakjackal: the reason for the failure is as follows:10:02
zygakjackal: the definitions are mutually exclusive10:02
zygakjackal: the plug definitions  at the top of the snap yaml are global10:02
zygakjackal: if an app has no plugs or slots defined it gets access to *all* plugs and slots defined at the global level10:02
zygakjackal: the ctr app is one example in your yaml10:03
zygait will get access to docker-privileged, k8s-kubelet  and k8s-kubeproxy10:03
zygakjackal: snapd does not detect mutually exclusive plugs or slots from being connected10:03
zygakjackal: apparmor parser detects the conflicting permissions granted and rejects the generated apparmor profile10:03
zygakjackal: that is all10:04
kjackalthank you zyga I will need some time to ingest exactly what you said, and I will get back to you10:05
zygakjackal: I encourage you to seek clarifications for any of the items I listed at any time10:06
mborzeckicachio: hi, can we update fedora & centos images?10:57
mborzeckicachio: seems like there,s a bunch of pending updates that have not been applied yet10:58
cachiomborzecki: hi, yes, I just reviewed that because both have been updated but seems to be an error during the process11:06
cachioI'll fix that and recreate the images11:06
mupPR snapd#6712 opened: overlord/snapstate: add timings to critical task handlers and the backend <Created by stolowski> <https://github.com/snapcore/snapd/pull/6712>11:07
mborzeckicachio: ah, so it's not related to fedora/centos running tests, but rather a problem with gcp project config11:10
cachiomborzecki: yes11:13
cachioIt failed to create the image but the build is in green11:14
cachioI'll retrigger the image and poke this issue11:14
mborzeckispread does not build anymore, golang.org/x/net dropped the context package11:17
cachioniemeyer:  hey,  seems to be a permissons issue on gce, I wuold need this one https://paste.ubuntu.com/p/CHYvrgDnvC/11:17
cachiomborzecki: we are not creating any image because a change in the permissions11:24
cachiomborzecki: we need gustavo for this11:24
cachiomborzecki: I am trying to workaround that untils we fix the permissons issue11:25
zygamborzecki: thank you11:35
mupPR snapd#6713 opened: tests/upgrade/basic: restore SELinux context of /var/cache/fontconfig <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6713>11:40
mborzeckipstolowski: if you could ^^11:41
mborzeckizyga:  do you know of other classic snaps that may want to use opengl?11:41
* pstolowski lunch11:44
mupPR snapd#6714 opened: cmd/snap-confine: reject crafted /tmp/snap.$SNAP_NAME <Created by zyga> <https://github.com/snapcore/snapd/pull/6714>11:45
* cachio afk11:46
Girtablulu|Awayis it possible to set the value refresh.retain while packaging snapd and not just after it?11:51
=== ricab is now known as ricab|lunch
zygamborzecki: godot uses locally embedded libGL.so11:57
zygaGirtablulu|Away: no, not at present11:57
Girtablulu|Awaythanks for the answer11:58
mborzeckizyga: duh, why would they do that?11:59
zygamborzecki: it's one of the problems with snapcraft and GL today11:59
zygawe need to change that across the ecosystem to fix the problem11:59
zygaldd of godot https://www.irccloud.com/pastebin/0Y1v1Jfc/12:00
zygathis is not sustainable: we cannot expect to support new hardware when everything is frozen like  that12:00
zygamborzecki: I'm thinking of several solutions, happy to discuss12:00
zygamborzecki: one of those elements is to package a new shim gl library that snapcraft will use instead of the real libraries12:00
zygathe shim gl is just there to satisfy dependencies, it does not actually contain any gl system12:01
zygaat runtime it would always be supplied by snapd, even for things like mesa12:01
zygathe problem is that this is complex to execute12:01
zygaat the same time I don't see anything that doesn't involve fixing snaps12:01
jdstrandzyga (cc kjackal): I think you mispoke12:02
jdstrandzyga: the plugs at the top are only global if there are no plugs down below12:03
zyganot quite, if an app has zero plugs or slots defined, it does get all globally defined plugs and slots12:03
zygaI don't know if we have a way to say "I want none"12:03
zygalike plugs: []12:03
zygaor if snapcraft would not remove that12:04
zyga"down below" I assume you mean at app level?12:04
jdstrandalso, I used the pasted snap.yaml and there were no issues12:04
zygathat's odd12:05
jdstrandzyga, kjackal: ^12:05
zygajdstrand: offtopic: https://github.com/snapcore/snapd/pull/671412:06
mupPR #6714: cmd/snap-confine: reject crafted /tmp/snap.$SNAP_NAME <Created by zyga> <https://github.com/snapcore/snapd/pull/6714>12:06
kjackalyes... it is failing over here... jdstrand how do you connect the two interfaces?12:06
jdstrandzyga: also, 'enable' has no plugs and it didn't get both interfaces. it got precisely 012:07
* zyga checks stuff12:07
jdstrandzyga: so it is operating how I understand it, not how you described it12:07
zygathat code was changed a while ago to fix a related bug12:08
zygaperhaps there were some unexpected consequences or perhaps I just plain misremember how it is supposed to work12:08
zygaaha, I see12:08
zygaso a plug or slot defined at top level is only added to apps or hooks if it is not bound to any app or hook12:09
zygathat's actually sensible and less surprising12:09
zygajdstrand: thank you for correcting me12:09
zygakjackal: jdstrand is correct, my previous explanation is invalid12:09
jdstrandkjackal: https://paste.ubuntu.com/p/BpGjHgmfmj/12:10
zygajdstrand: I'm working on https://github.com/snapcore/snapd/compare/master...zyga:fix/suse-audit-4?expand=112:10
zygajdstrand: I will add some spread tests for how this behaves before opening the PR though12:10
kjackaljdstrand: then why am I getting this: https://pastebin.ubuntu.com/p/ZxTF2j4tyg/12:10
jdstrandzyga: I'm going to pick daemon user today12:11
zygajdstrand: 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 group12:11
kjackalSorry I am very new to the strict confinement12:11
zygajdstrand: one thing that I'm worried about, with regards to the snapd group, is that we have no stable GIDs across distributions12:11
zygajdstrand: therefore it is unclear to me what should be placed in the core/snapd snaps12:11
jdstrandkjackal: what is the output of 'snap version'12:11
zygajdstrand: perhaps, however ugly, that should be checked inside the snap* commands12:11
kjackaljdstrand: http://paste.ubuntu.com/p/MdR8yPmzYc/ 2.3812:12
jdstrandzyga: if you set daemon user aside, the concept as a whole is that snapd has a predictable mapping12:12
zyga(so they remain being root-owned and root-group-owned and executable by all but perform an explicit check at runtime)12:12
jdstrandzyga: let me rephrase, if you set system users aside, there is a predicatable mapping12:12
zygajdstrand: I'm not sure I follow12:12
jdstrandzyga: 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 ecosystem12:14
jdstrandzyga: same is true for private-users (aka private-ids)12:14
zygajdstrand: perhaps I misunderstand how that answers one question: what is the GID of /usr/lib/snapd/snap-confine in the core snap12:15
jdstrandzyga: let me finish summarizing12:15
jdstrandzyga: with shared-users and private-users, they are prefixed with snap_12:16
jdstrandzyga: so claim a uid/gid range that is high and create the users/groups everywhere predictably12:16
zygajdstrand: hmmm12:17
zygajdstrand: I see12:17
zygainitially I was assuming that the "snapd" GID would be < 100012:17
jdstrandzyga: for 'system-users' (aka system-global-ids) there is no snap_ prefix, so we can't guarantee that the username, group isn't taken12:17
zygaso a typical system gid value12:17
zygajdstrand: so the new group would be snap_snapd?12:17
zygawith some high value?12:17
jdstrandso we would create these users on the fly if they don't exist, just like traditional packaging12:18
jdstrandthen snapd does a lookup and injects the gid for that system into the policy12:18
jdstrandzyga: hold on12:19
jdstrandzyga: oh wait, this whole time you are talking about the setgid user12:19
jdstrandzyga: I thought you were questioning the daemon user12:19
zygaah, no12:19
jdstrand /o\12:19
zygasorry, maybe I was not clear about that12:19
jdstrandok, please restate your concern12:19
* jdstrand flushes cache12:20
zygagiven that the core snap is shared by all systems alike12:20
zygathe same applies to snapd snap12:20
zygaI was wondering what we should do about the value of GID on key executables like snap-confine and snap inside said snaps12:20
zygamy starting point was that I was trying to add a typical system group that has GID < 100012:20
jdstrandkjackal: can you unsquashfs the snap you are trying to install and paste the squashfs-root/meta/snap.yaml12:20
zygabut coordinating that in the ecosystem is hard12:20
zygajdstrand: perhaps there's a better way, I just started thinking about this12:21
jdstrandzyga: ok right, that is likely a sisyphean task (trying to coordinate a low gid)12:22
ograjdstrand, 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
jdstrandzyga: I'm not even sure the line of demarcation (1000) can be depended upon everywhere12:22
jdstrandogra: sure. I think I have an idea about how to fix that in the base declaration12:23
ogralovely !12:23
zygajdstrand: perhaps the solution then is to not use the actual value12:23
kjackaljdstrand: Here it is: http://paste.ubuntu.com/p/hTWhshW239/ (learning new tricks)12:23
jdstrandogra: can you create a forum topic, then I can express my idea?12:24
zygajdstrand: but instead query if the calling user is a member of the snapd group12:24
zygawhatever that value is12:24
zygaand then deny or allow12:24
ograjdstrand, willcooke do12:24
ogra*will do12:24
* willcooke does too12:24
ograone tab too much12:24
* zyga notices a joke fly past him12:24
jdstrandthat is probably the most humorous tab complete fail I've seen (at least in recent memory :)12:25
jdstrandkjackal: that seems like a different snap.yaml from what you posted earlier12:27
* jdstrand will examine it12:28
jdstrandzyga: yes, I think that is what you must do12:28
zygajdstrand: thank you, I think, while unfortunate, it is unavoidable12:28
zygahmm, mount-observe is not working?12:29
jdstrandzyga: ie, yoy make it build time configurable what group snap-confine will verify. then the packager ensure that group exists12:29
zygajdstrand: how does that help?12:29
jdstrandzyga: it actually is ok. this is how lots of stuff works like this. eg, libvirt, lxd, docker, etc on their socket12:29
zygaI mean, are you aiming for names other than "snapd"12:29
jdstrandzyga: something like this:12:30
jdstrand./configure --with-group=whatever12:30
jdstrandthen for that build it is hardcoded to use 'whatever'12:31
jdstrandthen the suse packager does 'addgroup whatever'12:31
jdstrandthen it is all fine12:32
zygaright, I understand that12:32
zygaI'm seeing to understand why we want that to be configurable12:32
zygaI assume that "whatever" is a string, not an int12:32
jdstrandzyga: yes, precisely12:32
jdstrandnot a string12:32
zygaso how does this help with the core snap12:33
zygahow will the shared snap-confine be configured?12:33
jdstrandof course, that only works with the non-rexec snap-confine12:33
zygaor are you saying that the shared one should not enforce this check?12:33
zygaI see now12:33
zygahmm hmm12:33
zygaI would rather do something that works in both cases12:33
jdstrandyou can12:33
jdstrandbut then you'd want to make it so that if the group doesn't exist, use old behavior12:34
jdstrandotherwise new. that is a little weird12:34
zygaalso sometimes snap-confine starts on the inside of a mount namespace12:35
zygaso all a bit more complex12:35
jdstrandsuse doesn't want re-exec anyway afaik12:35
zygabut yeah, I think that's workable12:35
jdstranda first step might be just to support non-rexec using --with-user12:35
zygayes, that's right, but I prefer to create features that don't impede global reexec as a _technical_ possiblity12:35
jdstrandzyga: /etc always comes through though12:35
zygaoh, /etc12:35
zygahow I hate that we did that12:36
jdstrandcause this is in /etc/group12:36
zygawe should have not done that and instead forge special /etc12:36
jdstrandin this case it is a good thing :)12:36
zygaI think we should explore /etc being an empty tmpfs managed with mount backend12:36
zygait could ship symlinks for the 5-6 files we want12:36
jdstrandwell, in this case it doesn't have to be a bad thing12:36
zyga(those would go to hostfs)12:36
zygayes, I agree, it's just something that I recalled now that you mentioned it12:37
zyga(in context of the opencl test snap)12:37
jdstrandzyga: that's not going to work for people. there is a *ton* of stuff in /etc that snaps want. not least of which system-file12:37
zygajdstrand: but the things in /etc are not consistent12:37
zygaI know what you are saying but we should work towards *predictable* and managed /etc12:38
zygamany things will need to alter what /etc contains12:38
zygacurrently this is hard12:38
zygaand it is done so in a way that is not benefiting from snap-update-ns features12:38
jdstrandzyga: true, but that's life. people configure host certs, nss, users, groups, etc, etc, etc, etc12:38
zygassl certs don't work fully, it only works on ubuntu and debian AFAIK12:38
jdstrandanyway. I have other things to do. we can discuss something like that over a beer sometime12:39
zygayeah :)12:39
zygaI think we're in agreement12:39
zygaand I think I broke gid restore somehow12:39
* zyga debugs12:39
ograjdstrand, for later ... https://forum.snapcraft.io/t/kiosk-apps-with-xwayland-kiosk-launch-needing-an-x11-slot-that-makes-them-go-into-manual-review/1089212:39
kjackaljdstrand: I see you are using a test-k8s, is there a repository for this? Is it a fork of microk8s?12:40
jdstrandkjackal: I just took the yaml you pasted and changed the name and the 'command' lines12:42
jdstrandit isn't a thing12:42
jdstrandI'm now looking at your unsquashed one12:43
jdstrandogra: I did smart-ad-demo12:47
ograthx !12:48
jdstrandkjackal: I can't reproduce12:48
jdstrandkjackal: did you snap try or use a different snapd or anything else that might be relevant?12:49
jdstrandkjackal: can you perhaps try to install and connect everything in a clean vm?12:50
kjackalI am doing a snapcraft cleanbuild on the branch I pasted above and then snap install ./microk8s_latest.snap --dangerous12:50
jdstrandkjackal: what does 'snap list microk8s' say?12:50
kjackaljdstrand: http://paste.ubuntu.com/p/b4jKFyB2Y7/12:52
jdstrandkjackal: please 'snap remove microk8s' then paste: ind /var/lib/snapd -name "*microk8s*"12:54
kjackaljdstrand: 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
Chipacaprofile (null) for life12:56
kjackaljdstrand: here is the find in /var/lib/snapd12:58
mupPR snapd#6715 opened: interfaces/builtin/desktop: fonconfig v6/v7 cache handling on Fedora <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6715>12:59
jdstrandkjackal: ok, good. now install and do the snap connects one by one until you see the first error, then show me that series of commands12:59
kjackaljdstrand: Here it is https://pastebin.ubuntu.com/p/wgg7qsfyJq/13:02
jdstrandkjackal: can you paste /var/lib/snapd/apparmor/profiles/snap.microk8s.daemon-kubelet13:04
andyrockHi! 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
mupBug #1824188: Software tab is empty on clean 19.04 install <amd64> <apport-bug> <disco> <rls-dd-incoming> <gnome-initial-setup (Ubuntu):Confirmed> <snapd (Ubuntu):Invalid> <https://launchpad.net/bugs/1824188>13:05
kjackaljdstrand: here it is http://paste.ubuntu.com/p/VMVTNpm4CW/13:05
andyrockotherwise debugging a fix is a mess13:05
jdstrandkjackal: ok, the profile looks ok. let me try to parse that in different place. gimme a minute13:06
jdstrandkjackal: this is just a standard bionic system. not in a container or anything?13:07
kjackalno, that is my 18.04 laptop13:07
kjackalI have a Vm on aws running if you want me to try13:08
mupPR snapcraft#2526 closed: Release changelog for 3.4 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2526>13:11
jdstrandkjackal: ok, please remove microk8s, then install, then do:13:18
jdstrandsudo snap connect microk8s:k8s-kubeproxy :kubernetes-support13:18
jdstrandthen: /var/lib/snapd/apparmor/profiles/snap.microk8s.daemon-kubelet /tmp/before13:19
jdstrandsudo snap connect microk8s:k8s-kubelet :kubernetes-support13:19
jdstrandcp /var/lib/snapd/apparmor/profiles/snap.microk8s.daemon-kubelet /tmp/after13:19
jdstrandkjackal: I missed the 'cp' in the 'before'13:19
kjackaltrying it now13:21
=== ricab|lunch is now known as ricab
jdstrandkjackal: fyi, I can't reproduce in my bionic vm either13:22
jdstrandkjackal: once you have before and after, please paste: diff -Naur /tmp/before /tmp/after13:22
kjackalYes I understand jdstrand, no worries. I might have something wron on my system. Here is the diff: https://pastebin.ubuntu.com/p/TXpxKVm9X4/13:26
jdstrandkjackal: ok, can you paste both before and after?13:27
kjackaljdstrand: Here is the before: http://paste.ubuntu.com/p/qqcFm9Zxqk/13:28
kjackaljdstrand: here is the after: http://paste.ubuntu.com/p/HZFTPFmxk5/13:29
jdstrandthe profile looks fine13:29
jdstrandcan you make the snap available to me? perhaps via wormhole?13:30
jdstrand(snap install wormhole ; wormhole send /path/to/thing)13:30
dot-tobiaskyrofa / 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
dot-tobiasgo#L50) work for this?13:30
jdstrandkjackal: if using wormhole, privmsg me the code13:31
jdstranddot-tobias: by default a snap may setpriority to >= 013:32
jdstranddot-tobias: if it tries < 0, the call is denied but the application is not killed or anything13:32
jdstranddot-tobias: process-control allows for < 013:32
jdstrandkjackal: ok, downloading. it'll be ~10 minutes13:34
jdstrandkjackal: while we are waiting, what is 'apt-cache policy apparmor'13:36
roadmrjdstrand: 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:36
jdstrandroadmr: it depends on the interface. that is how content is setup, yes13:37
roadmrjdstrand: yes, the interface in question is content13:37
jdstrandroadmr: 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 decl13:38
kjackaljdstrand: Here is the apt apparmor policy http://paste.ubuntu.com/p/6dkCJmxNgf/13:38
roadmrjdstrand: ah, got it - that explains it very clearly13:39
dot-tobiasjdstrand: 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 from13:39
dot-tobias kill to a mere denial?)13:39
jdstrandroadmr: it is very easy to get the content stuff wrong. perhaps privmsg me and describe what you are trying to do?13:39
roadmrjdstrand: 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 before13:39
roadmrjdstrand: sure! I'll hit you in a sec13:40
cwaynesorry we make things so tricky :)13:41
jdstranddot-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 condition13:41
pedronismvo: cachio: this one I reviewed a while ago, it just needs some tweaks: https://github.com/snapcore/snapd/pull/659413:59
mupPR #6594: [RFC] tests: run smoke tests on (almost) pristine systems <Created by mvo5> <https://github.com/snapcore/snapd/pull/6594>13:59
cachiopedronis: sure, I'll take a look, thanks14:02
mupPR snapd#6716 opened: store: serialize the acquisition of device sessions <Created by pedronis> <https://github.com/snapcore/snapd/pull/6716>14:03
mborzeckiheh, so i could not build spread, because context was removed from my tree of golang.org/x/net :/14:10
jdstrandkjackal: ok, with your snap in a vm, I am able to reproduce14:12
mupPR snapd#6643 closed: tests: deny ioctl - TIOCSTI with garbage in high bits <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6643>14:12
kjackaljdstrand: I will not be surprised if its something wrong I am doing14:13
jdstrandI'm not convined it is you14:14
jdstrandbut now I can debug14:14
jdstrandthe hooks14:15
jdstrandthe hooks are getting the profiles added14:15
jdstrandboth of them14:15
jdstrandzyga: ^14:16
zygathe question is, why should the hooks behave differently from apps that have no plugs assigned14:16
jdstrandkjackal: for now, you can workaround this be removing the hooks. this is a bug in snapd14:16
zygaI would argue they should not, rigth?14:16
zygapstolowski: ^ remember the hooks and interfaces?14:16
jdstrandzyga: they 100% should not imo14:16
zygajdstrand: I'll look now14:17
kjackalok, jdstrand, I will see what i can do, thanks14:17
zygaI see the bug14:17
jdstrandzyga: hooks can plugs stuff, they need to behave like apps14:18
jdstrandI think we agree14:18
jdstrandfyi, this is what I saw: https://paste.ubuntu.com/p/WhJQpHjKVQ/14:19
jdstrandafter I connected the second one14:19
jdstrandsnap.microk8s.daemon-kubelet and snap.microk8s.daemon-proxy correctly only have the one systemd_run, but all the hooks have two14:19
pstolowskizyga: what about them?14:21
zygapstolowski: wait a sec14:21
zygapatch upcoming14:21
jdstrandzyga: heh, I was gonna ask if you or someone else would work on it cause kjackal needs it, but hey, you answered that :)14:22
zygait's in my head14:23
jdstrandzyga: thank you :)14:23
zygajdstrand: I was working on uid/gid restore but that's more of a maze than I wanted14:23
zygabecause of random places we raise/lower privs14:23
jdstrandzyga: oh yes-- that is very deliberately setup14:23
zygabut a bit mysterious where we drop permanently14:24
kjackaljdstrand zyga: Thank you. I have to admit I kind of understand how profiles are used in the high level but I do not know how snapd manipulates them. Where should I go to learn more about the internals? Look at the snapd code?  Which snap would you consider the cleanest one?14:24
zygacurrently seccomp code does that14:24
zygaanyway, you will surely review the patch14:24
zygakjackal: read snapd code14:24
zygakjackal: specifically interfaces/*14:24
zygakjackal: I'm happy to answer questions14:24
jdstrandzyga: well, that is at the finish line :) note that my daemon user branch changes this a little14:24
kjackalcool, thanks zyga14:24
ijohnsonhey zyga, any chance you or someone else could take another look at https://github.com/snapcore/snapd/pull/6697 ?14:25
mupPR #6697: interfaces/daemon_notify: add {net,sys}_admin capabilities, update spread test <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/6697>14:25
zygakjackal: the general idea is that snapd collects pieces of information in Specification objects, one for each security backend; each backend knows how to materialize a specification into a set of files that govern the sandbox14:25
* zyga afk for a sec, sorry14:25
zygaijohnson: queued14:25
jdstrandijohnson: fyi, that is in my queue. I have rather strong opinions on it14:25
ijohnsonzyga: thanks!14:25
jdstrandijohnson: but I have to dig up all the reasons why I dislike it so much14:26
jdstrandzyga: fyi ^14:26
ijohnsonjdstrand: :-( but okay14:26
ijohnsonjdstrand: thanks for taking a look at it14:26
jdstrandit isn't so much the PR as the feature in general14:27
* Chipaca looks forward to jdstrand's Sonnet 4314:27
jdstrandI mean, the PR too, but the PR insofar as what systemd requires I don't like14:27
jdstrandChipaca: hehe. Sometimes I feel more Faulkner than Shakespeare14:30
* ijohnson returns the systemd-notify themed gift bask bought for jdstrand14:30
jdstrandijohnson: :) I'm not going to get to it today, but I will get to it. I want to be able to provide a path forward which requires a bit of study and archaeology14:31
ijohnsonjdstrand: thanks for the due diligence14:32
jdstrandkjackal: I suggest as a user, reading the forum 'doc' category for things interface related14:33
jdstrandkjackal: eg https://forum.snapcraft.io/search?q=interfaces%20category%3A1514:34
jdstrandkjackal: also, again, if you remove your hooks for now, you can proceed with your work. watch for zyga's PR and when it is committed, the fix should be in edge in the next day or so after. then you can 'snap refresh core --edge' and add back your hooks14:35
zygaIRL interrupt14:35
zygalooking after Lucy14:36
jdstrandzyga: cute name :)14:36
Chipacajdstrand: it's short for Lucifer14:52
zygajdstrand: Łucja :)14:59
zygalol Chipaca14:59
zygaback now, she's no longer crying :)15:02
zygaback to that hook bug15:03
mvopstolowski: want to join #ubuntu-desktop ? the topic of fc-cache came up15:11
pstolowskimvo: sure15:12
mvoChipaca: the desktop team is asking if we can reply to queries while seeding like get the list of categories15:13
Chipacamvo: yes we can15:13
Chipacamvo: as long as they retry15:13
mvoChipaca: aha, so they try to early?15:13
Chipacamvo: the problem isn't their querying while seeding (although "list of installed snaps" when it's in the middle of installing will be racy)15:14
mvoChipaca: want to join #ubuntu-desktop as well :)15:14
mupBug #1823988 changed: CAP_NET_ADMIN not being provided with the recommended plugs <Snappy:Invalid> <https://launchpad.net/bugs/1823988>15:17
cachiopedronis: PR updated15:26
zygakjackal: hey, would you mind reporting the bug please15:34
zygakjackal: I'm just working on the commit message and I'd love to reference a bug number15:34
kjackalok LP zyga?15:35
zygakjackal: please :-)15:35
zygaon snapd15:35
* cachio lunch15:36
kyrofadot-tobias, I'm sorry for the delay. Indeed, as jdstrand mentions, they've changed from kill to errno. However, my understanding is that it depends on kernel features that aren't available everywhere, and the Nextcloud snap is used on a number of operating systems, so I chose not to rely on that behavior15:44
jdstrandkyrofa: almost. the we do errno always. what is dependent on kernel features is logging with errno15:45
jdstrandkyrofa: hi btw :)15:45
jdstrandwe don't kill anymore anywhere15:46
kyrofajdstrand, hey! So to clarify, the behavior should be consistent across distros, but the denial itself may not show up in the syslog?15:46
jdstrandkyrofa: exactly15:46
kyrofaThat's good to know, I'm tired of maintaining that patch15:46
jdstrandkyrofa: I didn't look at the patch. please note if they fail on errno != 0, a patch is still needed15:47
jdstrandthat seems pretty unusual with setpriority though15:48
zygakjackal: bug number? :)15:51
kyrofajdstrand, it just calls setpriority and then getpriority to see if the setting took. If not, it whines and moves on15:51
kyrofadot-tobias, note that it tries to use -20 as the priority15:54
roadmrwhy is snap sign being a jerk to me :(15:54
roadmrerror: cannot sign assertion: cannot sign using GPG: /usr/bin/gpg --personal-digest-preferences SHA512 --default-key 0x65A81F29127BF1AC94AA1A4B735216CA804762D0 --detach-sign failed: exit status 2 ("gpg: signing failed: No such file or directory\ngpg: signing failed: No such file or directory\n")15:54
roadmrcat whatever.json | snap sign -k my-key-id15:54
Chipacaroadmr: hmm15:56
Chipacaroadmr: do you have /usr/bin/gpg?15:56
roadmr$ which gpg15:56
Chipacaactually the 'gpg: signing failed' thing seems to be from gpg itself15:56
Chipacaroadmr: do you have ~/.snap/gnupg/ ?15:56
kjackalzyga: just came out of a meeting, opening the bug now15:58
roadmrChipaca: yes, there it is15:58
roadmrChipaca: funny part is - this worked like 30 minutes ago15:58
roadmra case of run it once, it works, run it again, it fails15:59
roadmrah but interestingly - that key (--default-key 0x65A81F29127BF1AC94AA1A4B735216CA804762D0) does NOT exist15:59
roadmroh I lie, there it is16:01
Chipacaroadmr: you can poke into it by hand using gpg --homedir ~/.snap/gnupg16:01
Chipacaroadmr: maybe it's expired or sth?16:01
roadmrChipaca: I did, I can see the key; not expired, just created it 1 hour ago16:01
Chipacaroadmr: are you secretly time-traveling16:01
roadmrbusted :(16:02
Chipacaroadmr: can you try strace'ing it?16:02
Chipacaroadmr: 'snap sign' is client-side only, so just strace the snap process should give you results16:03
zygakjackal: even a small report, we can expand on it later16:03
roadmrcat pi3.json | strace -o ouch snap sign -k what20190412216:04
kjackalzyga: here it is https://bugs.launchpad.net/snapd/+bug/182455716:04
mupBug #1824557: Apparmor "Multiple definitions for hat systemd_run" in kubernetes-support interface <snapd:New> <https://launchpad.net/bugs/1824557>16:04
zygathank you16:05
roadmrChipaca: http://paste.ubuntu.com/p/2nmbnJwDhW/ makes no sense to me16:06
zygakjackal, jdstrand: https://github.com/snapcore/snapd/pull/671716:06
mupPR #6717: snap: fix interface bindings on implicit hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/6717>16:06
mupPR snapd#6717 opened: snap: fix interface bindings on implicit hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/6717>16:07
Chipacaroadmr: is that with -f ?16:08
roadmrChipaca: nope; just ran with -f and it's stuck now haha16:09
Chipacaroadmr: ah, yes it gets stuck unless you tell it not to trace select iirc16:10
Chipacaroadmr: -e '!select,pselect6,_newselect,clock_gettime'16:11
roadmrChipaca: http://paste.ubuntu.com/p/dzsDWwRhw4/16:11
Chipacaroadmr: i see something about pinentry telling gpg 'no such file or directory'16:13
roadmrwhats pinentry? :)16:13
Chipacaroadmr: the thing gpg talks to to prompt you for keys16:14
roadmrChipaca: ah, let me try using --passphrase to bypass that16:14
roadmragain, weird because it worked fine (tm) the first time16:14
roadmroh I can't use --passphrase when invoking snap sign :(16:15
Chipacaroadmr: maybe seahorse went away?16:15
roadmrwhats seahorse :)16:15
Chipacaroadmr: (it might be called something else now)16:15
Chipacaroadmr: the gnome pinentry16:15
roadmrthat's the graphical key thingy, right?16:15
roadmrshouldn't, I'm SSHing into a headless box16:15
roadmrlet me try disabling x forwarding just in case16:16
roadmrChipaca: yay it worked with x forwarding disabled \o/16:16
Chipacaroadmr: magic16:16
roadmrChipaca: sorry then, it appears it was my weird env :( mystified that it worked the first time16:17
roadmrthanks so much Chipaca !16:17
Chipacaroadmr: depending on how it worked the first time, maybe the remote agent broke, or maybe agent forwarding died16:17
Chipacamaybe when you first connected you didn't have a remote agent and then you did16:17
* Chipaca is just pulling guesses out anatomically improbably places16:18
roadmrall these things talking to each other can fail in intesting ways16:18
Chipacawith non-obvious silent fallbacks16:19
pedronisgpg could at least print the relevant file name :/16:20
roadmrmy thought exactly pedronis  :) having to strace to figure that out was interesting16:22
Chipacapedronis: but it wasn't a file name that failed; it's the agent saying "yes i launched pinentry" and then "nope"16:28
Chipacapedronis: lines 5713-5716 in http://paste.ubuntu.com/p/dzsDWwRhw4/16:28
=== pstolowski is now known as pstolowski|afk
Chipaca(no i don't know that protocol well enough to know if that was even close to an accurate rendition of what went down)16:30
pedronisChipaca: didn't gpg print a ENOENT without the filename16:32
Chipacapedronis: it looked like it but wasn't16:32
Chipaca(bad on gpg yes)16:32
jdstrandkjackal: zyga's PR shows another workaround: you can define your hooks explicitly in the yaml instead of implicitly. this would also workaround the issue16:36
jdstrand(according to the PR)16:36
zygajdstrand: good observation, correct!16:49
zygajdstrand: I'm reworking the PR a little, fixed the bug that pedronis showd, adding tests now16:50
* jdstrand nods16:58
zygapedronis: re, I pushed a fix and the updated test17:45
fluutI'm trying to run a snap and I get "cannot move to directory with preserved namespaces: Permission denied" The only place that string exists, according to google, is in the code. Any ideas?18:31
xnoxChipaca, was it you who asked about user sessions being allowed the other day? the unit is called systemd-user-sessions.service18:32
xnoxit was something about snapd18:32
kjackalthanks zyga18:42
kjackalthanks jdstrand18:42
zygafluut: hey19:02
zygafluut: I can help, please tell me more19:02
zygafluut: start with snap version output, also if you can, run dmesg | grep DENIED and show me what it prints19:02
zygafluut: or if you can, report a bug with that information and hand me the URL, you can do that on https://bugs.launchpad.net/snapd/+filebug19:08
* cachio afk19:36
zygajdstrand: hey, if still around, could you please look at https://github.com/snapcore/snapd/pull/6714/files19:52
mupPR #6714: cmd/snap-confine: reject crafted /tmp/snap.$SNAP_NAME <Created by zyga> <https://github.com/snapcore/snapd/pull/6714>19:52
zygait's +89,-64, mostly a test revamp but really crucial permission tweak19:52
* zyga EODs20:09
Chipacaxnox: I didn't ask, per se, but yes it was me :-)20:25
Chipacaxnox: thanks20:25

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!