| mborzecki | morning | 05:23 |
|---|---|---|
| mborzecki | xdg mime handling feels like a maze | 06:11 |
| mup | PR snapd#6709 closed: release: 2.38.1 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6709> | 06:46 |
| mborzecki | mvo: hi | 06:49 |
| mborzecki | mvo: can you upload 2.38.1 source packages to the releases page? | 06:50 |
| zyga | Good morning | 06:55 |
| zyga | A bit sleepy today | 06:55 |
| zyga | I stayed way too long hacking on snap confine last night | 06:56 |
| mborzecki | zyga: hey | 07:00 |
| mup | PR 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 | ||
| pstolowski | morning | 07:05 |
| mborzecki | pstolowski: hey | 07:08 |
| mborzecki | zyga: btw. tried 19.04 with my gt1030 and did not run into any problems (at least with proprietary drivers) | 07:08 |
| mup | PR 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 |
| mup | PR 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 review | 07:19 |
| mup | PR #6692: interfaces: cleanup internal tool lookup in system-key <Simple đ> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6692> | 07:19 |
| mup | PR 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 |
| zyga | mborzecki: curious why it didnât work for popey | 07:28 |
| mborzecki | zyga: do you know if there was a specific snap that failed for him? | 07:29 |
| zyga | No, I donât recall | 07:30 |
| mborzecki | 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 |
| mborzecki | hm maybe it's godot specific | 07:41 |
| mborzecki | zyga: fwiw godot is classic :/ | 07:42 |
| mborzecki | zyga: aand it doesn't work | 07:44 |
| mvo | mborzecki: hey, sorry for the delay, had a meeting | 07:50 |
| mvo | mborzecki: 2.38.1 is not really needed outside of ubuntu/debian, its only packaging changes | 07:50 |
| zyga | mborzecki: great, so it's consistent | 07:59 |
| zyga | mborzecki: so what did work and what did not work and what are the symptoms of not working? | 07:59 |
| zyga | man, it's cold today | 08:00 |
| mborzecki | zyga: confined snaps worked (core, core18), classic does not | 08:00 |
| zyga | mborzecki: that's most curious | 08:00 |
| zyga | mborzecki: if yo want to learn more please do, I'm going to keep pushing on bugfixes from last weeks | 08:01 |
| zyga | mborzecki: arguably | 08:08 |
| zyga | mborzecki: once we have the support for classic mount namespaces | 08:08 |
| zyga | mborzecki: we could enable driver support for classic snaps as well | 08:08 |
| * zyga is gardening email | 08:20 | |
| pstolowski | hmmmmm | 08:54 |
| pstolowski | why do we update fc-cache twice in LinkSnap - before and after changing current symlink? | 08:55 |
| mborzecki | pstolowski: the after part is bc you may be updating from pre-fc-cache version of core/snapd | 08:56 |
| pstolowski | (the second is probably a no-op if fc-cache finds all the files in place) | 08:56 |
| mborzecki | pstolowski: the before part will make sure the cache was updated before the snap is runnable | 08:57 |
| pstolowski | mborzecki: ah, i see, the logic there is a bit subtle | 08:58 |
| * Chipaca is having a paperwork-y kind of day | 09:10 | |
| pedronis | Chipaca: we never did but at this point we could remove the code about AnonymousDownloadURL from store, right? | 09:38 |
| Chipaca | pedronis: we have AnonymousDownloadURL code? | 09:39 |
| pedronis | Chipaca: we do | 09:39 |
| Chipaca | ah, AnonDownloadURL | 09:39 |
| kjackal | 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:48 |
| zyga | kjackal: hey, looks like a bug in snapd | 09:54 |
| zyga | kjackal: can you please report it | 09:54 |
| kjackal | Sure, seem like I cannot do two connections in the kubernetes support interface | 09:55 |
| zyga | can you tell me more how you got the two connections? | 09:56 |
| kjackal | sure | 09:58 |
| kjackal | let me push the yaml | 09:58 |
| Chipaca | pedronis: we'd have to check that in all cases the other url is populated though | 10:00 |
| kjackal | 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 |
| kjackal | Â | 10:01 |
| kjackal | The second connect is failing: | 10:01 |
| kjackal | >Â sudo snap connect microk8s:k8s-kubeproxy :kubernetes-support | 10:01 |
| kjackal | Â >Â sudo snap connect microk8s:k8s-kubelet :kubernetes-support | 10:01 |
| kjackal | error: cannot perform the following tasks: | 10:01 |
| kjackal | zyga: ^ | 10:01 |
| zyga | kjackal: the reason for the failure is as follows: | 10:02 |
| zyga | kjackal: the definitions are mutually exclusive | 10:02 |
| zyga | kjackal: the plug definitions at the top of the snap yaml are global | 10:02 |
| zyga | kjackal: if an app has no plugs or slots defined it gets access to *all* plugs and slots defined at the global level | 10:02 |
| zyga | kjackal: the ctr app is one example in your yaml | 10:03 |
| zyga | it will get access to docker-privileged, k8s-kubelet and k8s-kubeproxy | 10:03 |
| zyga | kjackal: snapd does not detect mutually exclusive plugs or slots from being connected | 10:03 |
| zyga | kjackal: apparmor parser detects the conflicting permissions granted and rejects the generated apparmor profile | 10:03 |
| zyga | kjackal: that is all | 10:04 |
| kjackal | thank you zyga I will need some time to ingest exactly what you said, and I will get back to you | 10:05 |
| kjackal | brb | 10:05 |
| zyga | kjackal: I encourage you to seek clarifications for any of the items I listed at any time | 10:06 |
| zyga | brb | 10:25 |
| mborzecki | cachio: hi, can we update fedora & centos images? | 10:57 |
| mborzecki | cachio: seems like there,s a bunch of pending updates that have not been applied yet | 10:58 |
| cachio | mborzecki: hi, yes, I just reviewed that because both have been updated but seems to be an error during the process | 11:06 |
| cachio | https://travis-ci.org/snapcore/spread-cron/builds/517200642#L2633 | 11:06 |
| cachio | I'll fix that and recreate the images | 11:06 |
| mup | PR 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 |
| mborzecki | cachio: ah, so it's not related to fedora/centos running tests, but rather a problem with gcp project config | 11:10 |
| cachio | mborzecki: yes | 11:13 |
| cachio | It failed to create the image but the build is in green | 11:14 |
| cachio | I'll retrigger the image and poke this issue | 11:14 |
| mborzecki | spread does not build anymore, golang.org/x/net dropped the context package | 11:17 |
| cachio | niemeyer: hey, seems to be a permissons issue on gce, I wuold need this one https://paste.ubuntu.com/p/CHYvrgDnvC/ | 11:17 |
| cachio | mborzecki: we are not creating any image because a change in the permissions | 11:24 |
| cachio | mborzecki: we need gustavo for this | 11:24 |
| cachio | mborzecki: I am trying to workaround that untils we fix the permissons issue | 11:25 |
| zyga | mborzecki: thank you | 11:35 |
| mup | PR 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 |
| mborzecki | pstolowski: if you could ^^ | 11:41 |
| mborzecki | zyga: do you know of other classic snaps that may want to use opengl? | 11:41 |
| zyga | no | 11:41 |
| * pstolowski lunch | 11:44 | |
| mup | PR 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 afk | 11:46 | |
| Girtablulu|Away | is 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 | ||
| zyga | mborzecki: godot uses locally embedded libGL.so | 11:57 |
| zyga | Girtablulu|Away: no, not at present | 11:57 |
| Girtablulu|Away | thanks for the answer | 11:58 |
| mborzecki | zyga: duh, why would they do that? | 11:59 |
| zyga | mborzecki: it's one of the problems with snapcraft and GL today | 11:59 |
| zyga | we need to change that across the ecosystem to fix the problem | 11:59 |
| zyga | ldd of godot https://www.irccloud.com/pastebin/0Y1v1Jfc/ | 12:00 |
| zyga | this is not sustainable: we cannot expect to support new hardware when everything is frozen like that | 12:00 |
| zyga | mborzecki: I'm thinking of several solutions, happy to discuss | 12:00 |
| zyga | mborzecki: one of those elements is to package a new shim gl library that snapcraft will use instead of the real libraries | 12:00 |
| zyga | the shim gl is just there to satisfy dependencies, it does not actually contain any gl system | 12:01 |
| zyga | at runtime it would always be supplied by snapd, even for things like mesa | 12:01 |
| zyga | the problem is that this is complex to execute | 12:01 |
| zyga | at the same time I don't see anything that doesn't involve fixing snaps | 12:01 |
| jdstrand | zyga (cc kjackal): I think you mispoke | 12:02 |
| zyga | oh? | 12:03 |
| jdstrand | zyga: the plugs at the top are only global if there are no plugs down below | 12:03 |
| zyga | not quite, if an app has zero plugs or slots defined, it does get all globally defined plugs and slots | 12:03 |
| zyga | I don't know if we have a way to say "I want none" | 12:03 |
| zyga | like plugs: [] | 12:03 |
| zyga | or if snapcraft would not remove that | 12:04 |
| zyga | "down below" I assume you mean at app level? | 12:04 |
| jdstrand | yes | 12:04 |
| jdstrand | also, I used the pasted snap.yaml and there were no issues | 12:04 |
| jdstrand | https://paste.ubuntu.com/p/sRcydgPNhb/ | 12:05 |
| zyga | hmmm | 12:05 |
| zyga | that's odd | 12:05 |
| jdstrand | zyga, kjackal: ^ | 12:05 |
| zyga | jdstrand: offtopic: https://github.com/snapcore/snapd/pull/6714 | 12:06 |
| mup | PR #6714: cmd/snap-confine: reject crafted /tmp/snap.$SNAP_NAME <Created by zyga> <https://github.com/snapcore/snapd/pull/6714> | 12:06 |
| kjackal | yes... it is failing over here... jdstrand how do you connect the two interfaces? | 12:06 |
| jdstrand | zyga: also, 'enable' has no plugs and it didn't get both interfaces. it got precisely 0 | 12:07 |
| zyga | hmm | 12:07 |
| * zyga checks stuff | 12:07 | |
| jdstrand | zyga: so it is operating how I understand it, not how you described it | 12:07 |
| zyga | that code was changed a while ago to fix a related bug | 12:08 |
| zyga | perhaps there were some unexpected consequences or perhaps I just plain misremember how it is supposed to work | 12:08 |
| zyga | aha, I see | 12:08 |
| zyga | 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 |
| zyga | that's actually sensible and less surprising | 12:09 |
| zyga | jdstrand: thank you for correcting me | 12:09 |
| zyga | kjackal: jdstrand is correct, my previous explanation is invalid | 12:09 |
| jdstrand | kjackal: https://paste.ubuntu.com/p/BpGjHgmfmj/ | 12:10 |
| zyga | jdstrand: I'm working on https://github.com/snapcore/snapd/compare/master...zyga:fix/suse-audit-4?expand=1 | 12:10 |
| zyga | jdstrand: I will add some spread tests for how this behaves before opening the PR though | 12:10 |
| kjackal | jdstrand: then why am I getting this: https://pastebin.ubuntu.com/p/ZxTF2j4tyg/ | 12:10 |
| jdstrand | zyga: I'm going to pick daemon user today | 12:11 |
| zyga | 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 |
| zyga | pick? | 12:11 |
| kjackal | Sorry I am very new to the strict confinement | 12:11 |
| zyga | 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 |
| zyga | jdstrand: therefore it is unclear to me what should be placed in the core/snapd snaps | 12:11 |
| jdstrand | kjackal: what is the output of 'snap version' | 12:11 |
| zyga | jdstrand: perhaps, however ugly, that should be checked inside the snap* commands | 12:11 |
| kjackal | jdstrand: http://paste.ubuntu.com/p/MdR8yPmzYc/ 2.38 | 12:12 |
| jdstrand | zyga: if you set daemon user aside, the concept as a whole is that snapd has a predictable mapping | 12: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 |
| jdstrand | zyga: let me rephrase, if you set system users aside, there is a predicatable mapping | 12:12 |
| zyga | jdstrand: I'm not sure I follow | 12:12 |
| jdstrand | 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 |
| jdstrand | zyga: same is true for private-users (aka private-ids) | 12:14 |
| zyga | 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 |
| jdstrand | zyga: let me finish summarizing | 12:15 |
| jdstrand | zyga: with shared-users and private-users, they are prefixed with snap_ | 12:16 |
| jdstrand | zyga: so claim a uid/gid range that is high and create the users/groups everywhere predictably | 12:16 |
| zyga | jdstrand: hmmm | 12:17 |
| zyga | jdstrand: I see | 12:17 |
| zyga | initially I was assuming that the "snapd" GID would be < 1000 | 12:17 |
| jdstrand | 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 |
| zyga | so a typical system gid value | 12:17 |
| zyga | jdstrand: so the new group would be snap_snapd? | 12:17 |
| zyga | with some high value? | 12:17 |
| jdstrand | so we would create these users on the fly if they don't exist, just like traditional packaging | 12:18 |
| jdstrand | then snapd does a lookup and injects the gid for that system into the policy | 12:18 |
| jdstrand | zyga: hold on | 12:19 |
| jdstrand | zyga: oh wait, this whole time you are talking about the setgid user | 12:19 |
| zyga | correct | 12:19 |
| jdstrand | zyga: I thought you were questioning the daemon user | 12:19 |
| zyga | ah, no | 12:19 |
| jdstrand | /o\ | 12:19 |
| zyga | sorry, maybe I was not clear about that | 12:19 |
| jdstrand | ok, please restate your concern | 12:19 |
| zyga | ok | 12:20 |
| * jdstrand flushes cache | 12:20 | |
| zyga | given that the core snap is shared by all systems alike | 12:20 |
| zyga | the same applies to snapd snap | 12:20 |
| zyga | 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 |
| zyga | my starting point was that I was trying to add a typical system group that has GID < 1000 | 12:20 |
| jdstrand | kjackal: can you unsquashfs the snap you are trying to install and paste the squashfs-root/meta/snap.yaml | 12:20 |
| zyga | but coordinating that in the ecosystem is hard | 12:20 |
| zyga | jdstrand: perhaps there's a better way, I just started thinking about this | 12:21 |
| jdstrand | zyga: ok right, that is likely a sisyphean task (trying to coordinate a low gid) | 12:22 |
| ogra | 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 |
| jdstrand | zyga: I'm not even sure the line of demarcation (1000) can be depended upon everywhere | 12:22 |
| jdstrand | ogra: sure. I think I have an idea about how to fix that in the base declaration | 12:23 |
| ogra | lovely ! | 12:23 |
| zyga | jdstrand: perhaps the solution then is to not use the actual value | 12:23 |
| kjackal | jdstrand: Here it is: http://paste.ubuntu.com/p/hTWhshW239/ (learning new tricks) | 12:23 |
| jdstrand | ogra: can you create a forum topic, then I can express my idea? | 12:24 |
| zyga | jdstrand: but instead query if the calling user is a member of the snapd group | 12:24 |
| zyga | whatever that value is | 12:24 |
| zyga | and then deny or allow | 12:24 |
| ogra | jdstrand, willcooke do | 12:24 |
| ogra | HAHA | 12:24 |
| ogra | *will do | 12:24 |
| willcooke | :D | 12:24 |
| * willcooke does too | 12:24 | |
| ogra | one tab too much | 12:24 |
| jdstrand | hehehe | 12:24 |
| * zyga notices a joke fly past him | 12:24 | |
| jdstrand | that is probably the most humorous tab complete fail I've seen (at least in recent memory :) | 12:25 |
| ogra | :D | 12:25 |
| jdstrand | kjackal: that seems like a different snap.yaml from what you posted earlier | 12:27 |
| * jdstrand will examine it | 12:28 | |
| jdstrand | zyga: yes, I think that is what you must do | 12:28 |
| zyga | jdstrand: thank you, I think, while unfortunate, it is unavoidable | 12:28 |
| zyga | hmm, mount-observe is not working? | 12:29 |
| zyga | https://paste.ubuntu.com/p/fpFsX36ZCb/ | 12:29 |
| jdstrand | zyga: ie, yoy make it build time configurable what group snap-confine will verify. then the packager ensure that group exists | 12:29 |
| zyga | jdstrand: how does that help? | 12:29 |
| jdstrand | zyga: it actually is ok. this is how lots of stuff works like this. eg, libvirt, lxd, docker, etc on their socket | 12:29 |
| zyga | I mean, are you aiming for names other than "snapd" | 12:29 |
| jdstrand | zyga: something like this: | 12:30 |
| jdstrand | ./configure --with-group=whatever | 12:30 |
| jdstrand | then for that build it is hardcoded to use 'whatever' | 12:31 |
| jdstrand | then the suse packager does 'addgroup whatever' | 12:31 |
| jdstrand | then it is all fine | 12:32 |
| zyga | right, I understand that | 12:32 |
| zyga | I'm seeing to understand why we want that to be configurable | 12:32 |
| zyga | I assume that "whatever" is a string, not an int | 12:32 |
| jdstrand | zyga: yes, precisely | 12:32 |
| jdstrand | not a string | 12:32 |
| zyga | ooh | 12:32 |
| zyga | hmmmm | 12:32 |
| zyga | so how does this help with the core snap | 12:33 |
| zyga | how will the shared snap-confine be configured? | 12:33 |
| jdstrand | of course, that only works with the non-rexec snap-confine | 12:33 |
| zyga | or are you saying that the shared one should not enforce this check? | 12:33 |
| zyga | I see now | 12:33 |
| zyga | hmm hmm | 12:33 |
| zyga | I would rather do something that works in both cases | 12:33 |
| jdstrand | you can | 12:33 |
| jdstrand | --with-group=snapd | 12:34 |
| jdstrand | but then you'd want to make it so that if the group doesn't exist, use old behavior | 12:34 |
| zyga | indeed | 12:34 |
| jdstrand | otherwise new. that is a little weird | 12:34 |
| zyga | also sometimes snap-confine starts on the inside of a mount namespace | 12:35 |
| zyga | so all a bit more complex | 12:35 |
| jdstrand | suse doesn't want re-exec anyway afaik | 12:35 |
| zyga | but yeah, I think that's workable | 12:35 |
| jdstrand | a first step might be just to support non-rexec using --with-user | 12:35 |
| zyga | yes, that's right, but I prefer to create features that don't impede global reexec as a _technical_ possiblity | 12:35 |
| jdstrand | zyga: /etc always comes through though | 12:35 |
| zyga | oh, /etc | 12:35 |
| zyga | how I hate that we did that | 12:36 |
| jdstrand | cause this is in /etc/group | 12:36 |
| zyga | we should have not done that and instead forge special /etc | 12:36 |
| jdstrand | in this case it is a good thing :) | 12:36 |
| zyga | I think we should explore /etc being an empty tmpfs managed with mount backend | 12:36 |
| zyga | it could ship symlinks for the 5-6 files we want | 12:36 |
| jdstrand | well, in this case it doesn't have to be a bad thing | 12:36 |
| zyga | (those would go to hostfs) | 12:36 |
| zyga | yes, I agree, it's just something that I recalled now that you mentioned it | 12:37 |
| zyga | (in context of the opencl test snap) | 12:37 |
| jdstrand | 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 |
| zyga | jdstrand: but the things in /etc are not consistent | 12:37 |
| zyga | I know what you are saying but we should work towards *predictable* and managed /etc | 12:38 |
| zyga | many things will need to alter what /etc contains | 12:38 |
| zyga | currently this is hard | 12:38 |
| zyga | and it is done so in a way that is not benefiting from snap-update-ns features | 12:38 |
| jdstrand | zyga: true, but that's life. people configure host certs, nss, users, groups, etc, etc, etc, etc | 12:38 |
| zyga | ssl certs don't work fully, it only works on ubuntu and debian AFAIK | 12:38 |
| jdstrand | anyway. I have other things to do. we can discuss something like that over a beer sometime | 12:39 |
| zyga | yeah :) | 12:39 |
| zyga | I think we're in agreement | 12:39 |
| zyga | and I think I broke gid restore somehow | 12:39 |
| * zyga debugs | 12:39 | |
| ogra | 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:39 |
| kjackal | jdstrand: I see you are using a test-k8s, is there a repository for this? Is it a fork of microk8s? | 12:40 |
| jdstrand | kjackal: I just took the yaml you pasted and changed the name and the 'command' lines | 12:42 |
| jdstrand | it isn't a thing | 12:42 |
| jdstrand | I'm now looking at your unsquashed one | 12:43 |
| kjackal | thanks | 12:43 |
| jdstrand | ogra: I did smart-ad-demo | 12:47 |
| ogra | thx ! | 12:48 |
| jdstrand | kjackal: I can't reproduce | 12:48 |
| jdstrand | kjackal: did you snap try or use a different snapd or anything else that might be relevant? | 12:49 |
| jdstrand | kjackal: can you perhaps try to install and connect everything in a clean vm? | 12:50 |
| kjackal | I am doing a snapcraft cleanbuild on the branch I pasted above and then snap install ./microk8s_latest.snap --dangerous | 12:50 |
| jdstrand | kjackal: what does 'snap list microk8s' say? | 12:50 |
| kjackal | jdstrand: http://paste.ubuntu.com/p/b4jKFyB2Y7/ | 12:52 |
| jdstrand | kjackal: please 'snap remove microk8s' then paste: ind /var/lib/snapd -name "*microk8s*" | 12:54 |
| kjackal | 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 |
| jdstrand | s/ind/find/ | 12:54 |
| Chipaca | profile (null) for life | 12:56 |
| kjackal | jdstrand: here is the find in /var/lib/snapd | 12:58 |
| kjackal | https://pastebin.ubuntu.com/p/jTRkZYFPW2/ | 12:58 |
| mup | PR 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 |
| kjackal | https://pastebin.ubuntu.com/p/3ggcdDVFvq/ | 12:59 |
| jdstrand | 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 | 12:59 |
| kjackal | jdstrand: Here it is https://pastebin.ubuntu.com/p/wgg7qsfyJq/ | 13:02 |
| jdstrand | kjackal: can you paste /var/lib/snapd/apparmor/profiles/snap.microk8s.daemon-kubelet | 13:04 |
| andyrock | 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 |
| mup | Bug #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 |
| kjackal | jdstrand: here it is http://paste.ubuntu.com/p/VMVTNpm4CW/ | 13:05 |
| andyrock | otherwise debugging a fix is a mess | 13:05 |
| jdstrand | kjackal: ok, the profile looks ok. let me try to parse that in different place. gimme a minute | 13:06 |
| jdstrand | kjackal: this is just a standard bionic system. not in a container or anything? | 13:07 |
| kjackal | no, that is my 18.04 laptop | 13:07 |
| kjackal | I have a Vm on aws running if you want me to try | 13:08 |
| jdstrand | no | 13:09 |
| mup | PR snapcraft#2526 closed: Release changelog for 3.4 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2526> | 13:11 |
| jdstrand | kjackal: ok, please remove microk8s, then install, then do: | 13:18 |
| jdstrand | sudo snap connect microk8s:k8s-kubeproxy :kubernetes-support | 13:18 |
| jdstrand | then: /var/lib/snapd/apparmor/profiles/snap.microk8s.daemon-kubelet /tmp/before | 13:19 |
| jdstrand | sudo snap connect microk8s:k8s-kubelet :kubernetes-support | 13:19 |
| jdstrand | then: | 13:19 |
| jdstrand | cp /var/lib/snapd/apparmor/profiles/snap.microk8s.daemon-kubelet /tmp/after | 13:19 |
| jdstrand | kjackal: I missed the 'cp' in the 'before' | 13:19 |
| kjackal | trying it now | 13:21 |
| === ricab|lunch is now known as ricab | ||
| jdstrand | kjackal: fyi, I can't reproduce in my bionic vm either | 13:22 |
| jdstrand | kjackal: once you have before and after, please paste: diff -Naur /tmp/before /tmp/after | 13:22 |
| kjackal | 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:26 |
| jdstrand | kjackal: ok, can you paste both before and after? | 13:27 |
| kjackal | jdstrand: Here is the before: http://paste.ubuntu.com/p/qqcFm9Zxqk/ | 13:28 |
| kjackal | jdstrand: here is the after: http://paste.ubuntu.com/p/HZFTPFmxk5/ | 13:29 |
| jdstrand | ok | 13:29 |
| jdstrand | the profile looks fine | 13:29 |
| jdstrand | can you make the snap available to me? perhaps via wormhole? | 13:30 |
| jdstrand | (snap install wormhole ; wormhole send /path/to/thing) | 13:30 |
| dot-tobias | 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 |
| dot-tobias | go#L50) work for this? | 13:30 |
| jdstrand | kjackal: if using wormhole, privmsg me the code | 13:31 |
| jdstrand | dot-tobias: by default a snap may setpriority to >= 0 | 13:32 |
| jdstrand | dot-tobias: if it tries < 0, the call is denied but the application is not killed or anything | 13:32 |
| jdstrand | dot-tobias: process-control allows for < 0 | 13:32 |
| jdstrand | kjackal: ok, downloading. it'll be ~10 minutes | 13:34 |
| jdstrand | kjackal: while we are waiting, what is 'apt-cache policy apparmor' | 13:36 |
| roadmr | 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:36 |
| jdstrand | roadmr: it depends on the interface. that is how content is setup, yes | 13:37 |
| roadmr | jdstrand: yes, the interface in question is content | 13:37 |
| jdstrand | 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 |
| kjackal | jdstrand: Here is the apt apparmor policy http://paste.ubuntu.com/p/6dkCJmxNgf/ | 13:38 |
| roadmr | jdstrand: ah, got it - that explains it very clearly | 13:39 |
| dot-tobias | 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 |
| dot-tobias | kill to a mere denial?) | 13:39 |
| jdstrand | roadmr: it is very easy to get the content stuff wrong. perhaps privmsg me and describe what you are trying to do? | 13:39 |
| roadmr | 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:39 |
| roadmr | jdstrand: sure! I'll hit you in a sec | 13:40 |
| cwayne | sorry we make things so tricky :) | 13:41 |
| jdstrand | 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:41 |
| pedronis | mvo: cachio: this one I reviewed a while ago, it just needs some tweaks: https://github.com/snapcore/snapd/pull/6594 | 13:59 |
| mup | PR #6594: [RFC] tests: run smoke tests on (almost) pristine systems <Created by mvo5> <https://github.com/snapcore/snapd/pull/6594> | 13:59 |
| cachio | pedronis: sure, I'll take a look, thanks | 14:02 |
| mup | PR snapd#6716 opened: store: serialize the acquisition of device sessions <Created by pedronis> <https://github.com/snapcore/snapd/pull/6716> | 14:03 |
| mborzecki | heh, so i could not build spread, because context was removed from my tree of golang.org/x/net :/ | 14:10 |
| jdstrand | kjackal: ok, with your snap in a vm, I am able to reproduce | 14:12 |
| mup | PR 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 |
| kjackal | jdstrand: I will not be surprised if its something wrong I am doing | 14:13 |
| jdstrand | I'm not convined it is you | 14:14 |
| jdstrand | but now I can debug | 14:14 |
| jdstrand | the hooks | 14:15 |
| jdstrand | the hooks are getting the profiles added | 14:15 |
| jdstrand | both of them | 14:15 |
| jdstrand | zyga: ^ | 14:16 |
| zyga | ah | 14:16 |
| zyga | indeed! | 14:16 |
| zyga | the question is, why should the hooks behave differently from apps that have no plugs assigned | 14:16 |
| jdstrand | kjackal: for now, you can workaround this be removing the hooks. this is a bug in snapd | 14:16 |
| zyga | I would argue they should not, rigth? | 14:16 |
| zyga | pstolowski: ^ remember the hooks and interfaces? | 14:16 |
| jdstrand | zyga: they 100% should not imo | 14:16 |
| zyga | jdstrand: I'll look now | 14:17 |
| kjackal | ok, jdstrand, I will see what i can do, thanks | 14:17 |
| zyga | I see the bug | 14:17 |
| zyga | man | 14:17 |
| jdstrand | zyga: hooks can plugs stuff, they need to behave like apps | 14:18 |
| jdstrand | I think we agree | 14:18 |
| zyga | yes | 14:18 |
| jdstrand | fyi, this is what I saw: https://paste.ubuntu.com/p/WhJQpHjKVQ/ | 14:19 |
| jdstrand | after I connected the second one | 14:19 |
| jdstrand | snap.microk8s.daemon-kubelet and snap.microk8s.daemon-proxy correctly only have the one systemd_run, but all the hooks have two | 14:19 |
| pstolowski | zyga: what about them? | 14:21 |
| zyga | pstolowski: wait a sec | 14:21 |
| zyga | patch upcoming | 14:21 |
| jdstrand | zyga: 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 |
| zyga | yep | 14:23 |
| zyga | it's in my head | 14:23 |
| jdstrand | zyga: thank you :) | 14:23 |
| zyga | jdstrand: I was working on uid/gid restore but that's more of a maze than I wanted | 14:23 |
| zyga | because of random places we raise/lower privs | 14:23 |
| jdstrand | zyga: oh yes-- that is very deliberately setup | 14:23 |
| zyga | yes | 14:24 |
| zyga | but a bit mysterious where we drop permanently | 14:24 |
| kjackal | jdstrand 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 |
| zyga | currently seccomp code does that | 14:24 |
| zyga | anyway, you will surely review the patch | 14:24 |
| zyga | kjackal: read snapd code | 14:24 |
| zyga | kjackal: specifically interfaces/* | 14:24 |
| zyga | kjackal: I'm happy to answer questions | 14:24 |
| jdstrand | zyga: well, that is at the finish line :) note that my daemon user branch changes this a little | 14:24 |
| kjackal | cool, thanks zyga | 14:24 |
| ijohnson | hey zyga, any chance you or someone else could take another look at https://github.com/snapcore/snapd/pull/6697 ? | 14:25 |
| mup | PR #6697: interfaces/daemon_notify: add {net,sys}_admin capabilities, update spread test <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/6697> | 14:25 |
| zyga | kjackal: 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 sandbox | 14:25 |
| * zyga afk for a sec, sorry | 14:25 | |
| zyga | ijohnson: queued | 14:25 |
| jdstrand | ijohnson: fyi, that is in my queue. I have rather strong opinions on it | 14:25 |
| ijohnson | zyga: thanks! | 14:25 |
| jdstrand | ijohnson: but I have to dig up all the reasons why I dislike it so much | 14:26 |
| jdstrand | zyga: fyi ^ | 14:26 |
| ijohnson | jdstrand: :-( but okay | 14:26 |
| ijohnson | jdstrand: thanks for taking a look at it | 14:26 |
| jdstrand | it isn't so much the PR as the feature in general | 14:27 |
| * Chipaca looks forward to jdstrand's Sonnet 43 | 14:27 | |
| jdstrand | I mean, the PR too, but the PR insofar as what systemd requires I don't like | 14:27 |
| jdstrand | Chipaca: hehe. Sometimes I feel more Faulkner than Shakespeare | 14:30 |
| * ijohnson returns the systemd-notify themed gift bask bought for jdstrand | 14:30 | |
| ijohnson | *basket | 14:30 |
| jdstrand | ijohnson: :) 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 archaeology | 14:31 |
| ijohnson | jdstrand: thanks for the due diligence | 14:32 |
| jdstrand | kjackal: I suggest as a user, reading the forum 'doc' category for things interface related | 14:33 |
| kjackal | thanks | 14:33 |
| jdstrand | kjackal: eg https://forum.snapcraft.io/search?q=interfaces%20category%3A15 | 14:34 |
| jdstrand | kjackal: 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 hooks | 14:35 |
| zyga | IRL interrupt | 14:35 |
| zyga | looking after Lucy | 14:36 |
| zyga | (baby) | 14:36 |
| jdstrand | zyga: cute name :) | 14:36 |
| Chipaca | jdstrand: it's short for Lucifer | 14:52 |
| Chipaca | (probably) | 14:52 |
| zyga | jdstrand: Ĺucja :) | 14:59 |
| zyga | lol Chipaca | 14:59 |
| zyga | back now, she's no longer crying :) | 15:02 |
| zyga | back to that hook bug | 15:03 |
| jdstrand | hehe | 15:05 |
| mvo | pstolowski: want to join #ubuntu-desktop ? the topic of fc-cache came up | 15:11 |
| pstolowski | mvo: sure | 15:12 |
| mvo | Chipaca: the desktop team is asking if we can reply to queries while seeding like get the list of categories | 15:13 |
| Chipaca | mvo: yes we can | 15:13 |
| Chipaca | mvo: as long as they retry | 15:13 |
| mvo | Chipaca: aha, so they try to early? | 15:13 |
| Chipaca | mvo: 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 |
| mvo | Chipaca: want to join #ubuntu-desktop as well :) | 15:14 |
| Chipaca | sure | 15:14 |
| mup | Bug #1823988 changed: CAP_NET_ADMIN not being provided with the recommended plugs <Snappy:Invalid> <https://launchpad.net/bugs/1823988> | 15:17 |
| cachio | pedronis: PR updated | 15:26 |
| zyga | kjackal: hey, would you mind reporting the bug please | 15:34 |
| zyga | kjackal: I'm just working on the commit message and I'd love to reference a bug number | 15:34 |
| kjackal | ok LP zyga? | 15:35 |
| zyga | kjackal: please :-) | 15:35 |
| zyga | on snapd | 15:35 |
| * cachio lunch | 15:36 | |
| kyrofa | dot-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 behavior | 15:44 |
| jdstrand | kyrofa: almost. the we do errno always. what is dependent on kernel features is logging with errno | 15:45 |
| jdstrand | kyrofa: hi btw :) | 15:45 |
| jdstrand | we don't kill anymore anywhere | 15:46 |
| kyrofa | jdstrand, hey! So to clarify, the behavior should be consistent across distros, but the denial itself may not show up in the syslog? | 15:46 |
| jdstrand | kyrofa: exactly | 15:46 |
| kyrofa | That's good to know, I'm tired of maintaining that patch | 15:46 |
| jdstrand | kyrofa: I didn't look at the patch. please note if they fail on errno != 0, a patch is still needed | 15:47 |
| jdstrand | that seems pretty unusual with setpriority though | 15:48 |
| zyga | kjackal: bug number? :) | 15:51 |
| kyrofa | jdstrand, it just calls setpriority and then getpriority to see if the setting took. If not, it whines and moves on | 15:51 |
| kyrofa | dot-tobias, note that it tries to use -20 as the priority | 15:54 |
| roadmr | why is snap sign being a jerk to me :( | 15:54 |
| roadmr | error: 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 |
| roadmr | cat whatever.json | snap sign -k my-key-id | 15:54 |
| Chipaca | roadmr: hmm | 15:56 |
| Chipaca | roadmr: do you have /usr/bin/gpg? | 15:56 |
| roadmr | $ which gpg | 15:56 |
| roadmr | /usr/bin/gpg | 15:56 |
| Chipaca | actually the 'gpg: signing failed' thing seems to be from gpg itself | 15:56 |
| Chipaca | hm | 15:56 |
| Chipaca | roadmr: do you have ~/.snap/gnupg/ ? | 15:56 |
| kjackal | zyga: just came out of a meeting, opening the bug now | 15:58 |
| roadmr | Chipaca: yes, there it is | 15:58 |
| roadmr | Chipaca: funny part is - this worked like 30 minutes ago | 15:58 |
| roadmr | a case of run it once, it works, run it again, it fails | 15:59 |
| roadmr | ah but interestingly - that key (--default-key 0x65A81F29127BF1AC94AA1A4B735216CA804762D0) does NOT exist | 15:59 |
| roadmr | oh I lie, there it is | 16:01 |
| Chipaca | roadmr: you can poke into it by hand using gpg --homedir ~/.snap/gnupg | 16:01 |
| Chipaca | roadmr: maybe it's expired or sth? | 16:01 |
| roadmr | Chipaca: I did, I can see the key; not expired, just created it 1 hour ago | 16:01 |
| Chipaca | roadmr: are you secretly time-traveling | 16:01 |
| roadmr | busted :( | 16:02 |
| Chipaca | roadmr: can you try strace'ing it? | 16:02 |
| Chipaca | roadmr: 'snap sign' is client-side only, so just strace the snap process should give you results | 16:03 |
| zyga | kjackal: even a small report, we can expand on it later | 16:03 |
| roadmr | cat pi3.json | strace -o ouch snap sign -k what201904122 | 16:04 |
| kjackal | zyga: here it is https://bugs.launchpad.net/snapd/+bug/1824557 | 16:04 |
| mup | Bug #1824557: Apparmor "Multiple definitions for hat systemd_run" in kubernetes-support interface <snapd:New> <https://launchpad.net/bugs/1824557> | 16:04 |
| zyga | thank you | 16:05 |
| roadmr | Chipaca: http://paste.ubuntu.com/p/2nmbnJwDhW/ makes no sense to me | 16:06 |
| zyga | kjackal, jdstrand: https://github.com/snapcore/snapd/pull/6717 | 16:06 |
| mup | PR #6717: snap: fix interface bindings on implicit hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/6717> | 16:06 |
| mup | PR snapd#6717 opened: snap: fix interface bindings on implicit hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/6717> | 16:07 |
| Chipaca | roadmr: is that with -f ? | 16:08 |
| roadmr | Chipaca: nope; just ran with -f and it's stuck now haha | 16:09 |
| Chipaca | roadmr: ah, yes it gets stuck unless you tell it not to trace select iirc | 16:10 |
| Chipaca | roadmr: -e '!select,pselect6,_newselect,clock_gettime' | 16:11 |
| roadmr | Chipaca: http://paste.ubuntu.com/p/dzsDWwRhw4/ | 16:11 |
| Chipaca | roadmr: i see something about pinentry telling gpg 'no such file or directory' | 16:13 |
| roadmr | whats pinentry? :) | 16:13 |
| Chipaca | roadmr: the thing gpg talks to to prompt you for keys | 16:14 |
| roadmr | Chipaca: ah, let me try using --passphrase to bypass that | 16:14 |
| roadmr | again, weird because it worked fine (tm) the first time | 16:14 |
| roadmr | oh I can't use --passphrase when invoking snap sign :( | 16:15 |
| Chipaca | roadmr: maybe seahorse went away? | 16:15 |
| roadmr | whats seahorse :) | 16:15 |
| Chipaca | roadmr: (it might be called something else now) | 16:15 |
| Chipaca | roadmr: the gnome pinentry | 16:15 |
| roadmr | that's the graphical key thingy, right? | 16:15 |
| Chipaca | y | 16:15 |
| roadmr | shouldn't, I'm SSHing into a headless box | 16:15 |
| roadmr | let me try disabling x forwarding just in case | 16:16 |
| roadmr | Chipaca: yay it worked with x forwarding disabled \o/ | 16:16 |
| Chipaca | roadmr: magic | 16:16 |
| roadmr | Chipaca: sorry then, it appears it was my weird env :( mystified that it worked the first time | 16:17 |
| roadmr | thanks so much Chipaca ! | 16:17 |
| Chipaca | roadmr: depending on how it worked the first time, maybe the remote agent broke, or maybe agent forwarding died | 16:17 |
| Chipaca | maybe when you first connected you didn't have a remote agent and then you did | 16:17 |
| * Chipaca is just pulling guesses out anatomically improbably places | 16:18 | |
| Chipaca | improbable* | 16:18 |
| roadmr | all these things talking to each other can fail in intesting ways | 16:18 |
| Chipaca | with non-obvious silent fallbacks | 16:19 |
| pedronis | gpg could at least print the relevant file name :/ | 16:20 |
| roadmr | my thought exactly pedronis :) having to strace to figure that out was interesting | 16:22 |
| Chipaca | pedronis: but it wasn't a file name that failed; it's the agent saying "yes i launched pinentry" and then "nope" | 16:28 |
| Chipaca | pedronis: 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 |
| pedronis | Chipaca: didn't gpg print a ENOENT without the filename | 16:32 |
| Chipaca | pedronis: it looked like it but wasn't | 16:32 |
| Chipaca | (bad on gpg yes) | 16:32 |
| jdstrand | kjackal: zyga's PR shows another workaround: you can define your hooks explicitly in the yaml instead of implicitly. this would also workaround the issue | 16:36 |
| jdstrand | (according to the PR) | 16:36 |
| zyga | jdstrand: good observation, correct! | 16:49 |
| zyga | jdstrand: I'm reworking the PR a little, fixed the bug that pedronis showd, adding tests now | 16:50 |
| * jdstrand nods | 16:58 | |
| zyga | pedronis: re, I pushed a fix and the updated test | 17:45 |
| fluut | I'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 |
| xnox | Chipaca, was it you who asked about user sessions being allowed the other day? the unit is called systemd-user-sessions.service | 18:32 |
| xnox | it was something about snapd | 18:32 |
| kjackal | thanks zyga | 18:42 |
| kjackal | thanks jdstrand | 18:42 |
| zyga | re | 19:02 |
| zyga | fluut: hey | 19:02 |
| zyga | fluut: I can help, please tell me more | 19:02 |
| zyga | fluut: start with snap version output, also if you can, run dmesg | grep DENIED and show me what it prints | 19:02 |
| zyga | fluut: 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/+filebug | 19:08 |
| * cachio afk | 19:36 | |
| zyga | jdstrand: hey, if still around, could you please look at https://github.com/snapcore/snapd/pull/6714/files | 19:52 |
| mup | PR #6714: cmd/snap-confine: reject crafted /tmp/snap.$SNAP_NAME <Created by zyga> <https://github.com/snapcore/snapd/pull/6714> | 19:52 |
| zyga | it's +89,-64, mostly a test revamp but really crucial permission tweak | 19:52 |
| * zyga EODs | 20:09 | |
| Chipaca | xnox: I didn't ask, per se, but yes it was me :-) | 20:25 |
| Chipaca | xnox: thanks | 20:25 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!