[02:29] PR snapd#10306 opened: snap/quota: add CurrentMemoryUsage for current memory usage of a quota group === freenodecom changed the topic of #snappy to: This channel has moved to ##snappy. The topic is in violation of freenode policy: https://freenode.net/policies [03:03] This channel has been reopened with respect to the communities and new users. The topic is in violation of freenode policy: https://freenode.net/policies [03:03] The new channel is ##snappy === drizztbsd is now known as timothy === dob1_ is now known as dob1 [11:23] pedronis: i just saw you comment re debug api access while i was updating the PR to restrict it with rootAccess for stacktrace only (with a separate endpoint). shall I instead make it rootOnly for all debug api? [11:24] s/rootOnly/rootAccess/ [11:24] biab, lunch [11:38] so, I need some advice :-) [11:39] the microk8s snap ships a profile for containerd: https://github.com/ubuntu/microk8s/blob/master/microk8s-resources/containerd-profile [11:40] I don't think we want snaps to ship their own profiles, but I'm also not sure what is the best way forward === Mirv__ is now known as Mirv [11:40] one possibility would be to enhance the kubernetes-support interface, and add a sub-profile for containerd in there [11:41] another option is to add a containerd-support interface, and have the containerd-daemon use that [11:41] anything else? [11:47] mardy it's hard to pull permissions [11:47] mardy if it ships a profile it can load it [11:48] so you cannot revoke that without some extra new optional parameter that says it has an interface but wants a more limited version because it expects snapd to do stuff [11:48] note that the profile it ships is not in the snap.* namespace either [11:48] so it's really a case of a snap having permissions to define custom sandbox for something it manages [11:52] zyga: I'm not sure if I'm misunderstanding you, but in this case pulling permissions would be easier, because the microk8s snap is also developed by Canonical [11:52] it's "just" a matter of deciding where to put this profile, and how to load it [11:53] mardy I suspect that a snap interface _could_ load a profile from outside of the snap.* namespace but that is indeed new [11:53] mardy do you know if microk8s leaves its apparmor profile explicitly? [11:53] and sets up things to be in cri-containerd.apparmor.d profile? [11:53] I also wonder what you gain by moving that profile somewhere else [11:54] updates now would require updating snapd [11:54] arguably this is easier now [11:54] zyga: yes, a script reexecutes itself with aa-exec as unconfined, then loads the cri-containerd profile with apparmor_parser :-) [11:54] okay [11:54] zyga: but I see that here we have a subprofile, for example: https://github.com/snapcore/snapd/blob/master/interfaces/builtin/kubernetes_support.go#L66-L68 [11:54] I think as unfortunate as that is, it's cleaner if it's not in the snapd profile [11:55] and I wonder if we shouldn't do the same for containerd [11:55] hmmm [11:56] that's a profile for a specific binary though [11:56] how would you transition? [11:56] * ogra wonders what "cri-" stands for [11:56] (here microk8s must manually run things in that profile) [11:56] container runtime icannotmakeupmymind [11:56] haha [11:56] i like the last bit [11:57] zyga: AFAIU, containerd then would create specific apparmor profiles for its containers: https://docs.docker.com/engine/security/apparmor/ [11:59] mardy I guess with enough coordination it is possible [11:59] what do microk8s folks say? [12:04] zyga: I will ask them next :-) [12:12] mardy one thing being problematic here is that it may require a new assumes: snapdXYZ in the microk8s snap === pedronis_ is now known as pedronis [12:36] kubernetes-support microk8s:k8s-journald - - [12:36] kubernetes-support microk8s:k8s-kubelet - - [12:36] kubernetes-support microk8s:k8s-kubeproxy - - [12:36] kubernetes-support microk8s:kubernetes-support :kubernetes-support - [12:37] any idea why the last one is autoconnected, while the previous three are not? [12:40] mardy: the previous one is a new interface you're working on right? [12:43] pstolowski: no, I'm innocent here :-) [12:43] pstolowski: all those microk8s:k8s-* plugs are different flavors of the kubernetes-support interface [12:45] mardy I have a guess [12:45] actually [12:45] maybe not [12:45] can you share the slot and plug info? [12:45] I thought it's something but I'm not sure anymore [12:45] that info should help [12:47] zyga: https://github.com/ubuntu/microk8s/blob/feature/jdb/strict/snap/snapcraft.yaml#L26-L34 [12:47] or did you mean from snapd? [12:47] and can you share the snap decl assertion [12:47] no that's fine [12:48] snap known snap-declaration # I forget what you have to say here [12:51] zyga: you mean this? https://paste.ubuntu.com/p/tMZ3W9RQBV/ [12:52] yes [12:52] it has auto-connection on kubernetes-support [12:52] I wonder how the interface name matters in auto-connection rules [12:53] I think pedronis would know but I recall there was some language to constrain interface names as well [12:53] zyga: when you enable autoconnection on one interface, does that apply to all flavors? or do you need to list them explicitly? [12:54] flavour is just an attribute [12:54] it's not special in the system AFAIK [12:54] have a look at interfaces/policy as well [12:54] mardy: it applies to all unless there are extra constraint on it [12:54] I don't recall [12:54] hey ijohnson [12:54] hey zyga [12:54] mardy: for example on attributes or plug names [12:54] mmm.. here it looks like it's doing something special based on the flavor: https://github.com/snapcore/snapd/blob/master/interfaces/builtin/kubernetes_support.go#L306-L323 [12:54] mardy it could be that the core policy has something about it [12:54] zyga: how are things with you these days ? [12:55] mardy the core policy together witih snap decl on microk8s should have all the input to the engine that decides [12:55] ijohnson oh good, a bit over worked as usual but it's still fun [12:55] setting up CI lab for zephyr and linux boards [12:55] yeah I've heard about all the adventures in testing real metal boards with spread [12:55] looking into projects that do zephyr updates [12:56] looking into some linux updates for a gateway as well [12:56] ijohnson yeah, we're working with Linaro to extend spread to support using lava [12:56] or to be precise, to emit lava jobs [12:56] so that CI like gitlab or github can schedule lava jobs and collect results back [12:56] nice [12:57] yeah, though it took some convincing :D [12:57] :-D [12:58] I wish we could merge some of that back [12:58] that's always an option, I know everyone is busy [12:58] yeah I wish spread was more actively maintained as well [12:58] I mean everybody wishes everything was more actively maintained though haha [12:59] I think we can all collectively fork it if we're happy with that [12:59] I hope it's not needed [12:59] true always an option [12:59] anyways /me -> SU [12:59] o/ [13:34] ijohnson: this is probably something simple you can review https://github.com/snapcore/snapd/pull/10310 as you were in the discussions [13:34] is there any way for a snap to know if this is its first execution after boot? [13:35] pedronis: sure [13:38] the mikrok8s needs this, but their current way of getting this information requires access to /proc/1/environ: https://github.com/ubuntu/microk8s/blob/master/microk8s-resources/actions/common/utils.sh#L684-L686 [13:38] so I was wondering that, unless we have something like this already, maybe we could provide this information via a snapctl action? [13:58] mardy: that feels a bit broken, can they not just write a file to /tmp the first time they start and if that file exists it's not the first start ? [14:07] mardy: we try not to provide things via snapctl unless it's really snap specific or there's no other way to mediate the access [14:25] mvo: can you land https://github.com/snapcore/snapd/pull/10284 ? unrelated failures.. [14:25] mborzecki: ijohnson: I created https://github.com/snapcore/snapd/pull/10311 related to the SU discussion and 10255 [14:25] pstolowski: done [14:26] ty! === luisp is now known as luisp_ === luisp_ is now known as luisp__ === luisp__ is now known as luisp [14:35] pedronis: ack thanks for this [14:36] pedronis: related, how do you feel about making post to quotas related things authenticated? it currently is root only and it's ever so slightly annoying to me that I need to use sudo [14:38] ijohnson: uh, why didn't I think of that... :-) [14:39] mardy: haha no worries I'm sure this code works fine outside of confinement and wasn't written expecting to be confined at all [14:42] ijohnson: don't we set TMPDIR to something else, when running a snap? Or can confined snaps write to /tmp? [14:43] mardy: confined snaps have a different /tmp mounted for them, from the host system, a snap's /tmp is something like /tmp/snap_foobar/ [14:43] at least we don't, according to https://snapcraft.io/docs/environment-variables [14:43] ah, nice [14:43] mardy: so we don't set the TMPDIR value to something else, it still points to /tmp by default, but /tmp is not /tmp on the host [14:43] hey roadmr [14:43] ijohnson: nice [14:45] ijohnson: I think it's a bit premature to do that change, my current impression is that root still seems correct [14:46] pedronis: ack, as I said it's just slightly annoying for me to remember during development [14:48] o/ [15:15] pedronis: do you know the status of #8919 ? claudio marked it blocked waiting for some better API from Chris, but it's not clear to me better API was ever implemented [15:33] O Hi! [15:33] I need my cloak back [15:33] ;-) [15:34] om26er, #ubuntu-irc hands them out [15:35] (and the libera ones are much nicer too ... if you modify them a bit they turn into superhero capes 😉 ) [15:41] ijohnson: we need to resync with chris [16:05] pedronis: ack, I will leave the pr be then [16:38] ijohnson: btw, did you see I commented on https://github.com/snapcore/snapd/pull/9965 a while ago? [16:39] oh sorry yes I did see you commented on that, but forgot to respond / address your points [16:39] I will respond today [16:39] thanks [16:39] pedronis: what do you think of my proposal for https://github.com/snapcore/snapd/pull/10304#discussion_r639795752 ? [16:52] ijohnson: I commented making a suggestion [16:52] * ijohnson thanks [16:52] err [16:52] thanks pedronis [16:52] heh [17:02] pedronis: related to the default-providers question, is there also a possibly similar question for super-privileged snaps like lxd or docker being pulled in automatically that the user didn't consent to? I mean those snaps are strictly confined so probably it's fine? [17:32] ijohnson: no, that's different, also we would likely control which snaps can pull them in [17:33] ok makes sense