[00:35] PR pc-amd64-gadget#22 closed: Store changes [00:39] hrm [00:41] why does the home interface not allow me to read data produced by one snap via the other in a ~/snap//current/ subdir [00:41] ogra@acheron:~/snap/arduino-mhall119/current/Arduino/test$ esptool -cp /dev/ttyUSB0 -cd none -ca 0x40000 -cf test.ino.generic.bin [00:41] produces : [00:41] Nov 05 01:39:38 acheron audit[4633]: AVC apparmor="DENIED" operation="open" profile="snap.esptool.esptool" name="/home/ogra/snap/arduino-mhall119/5/Arduino/test/test.ino.generic.bin" pid=4633 comm="esptool" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 [00:42] funnily enough i can copy the file to ~/ and am allowed to open it [00:42] i'd have thought he home interface allows this ? [06:06] ogra: that is by design [06:06] Snaps cannot read each other’s data [06:15] morning [06:16] PR snapd#7718 closed: sandbox/seccomp: accept build ID generated by Go toolchain [06:27] hey mborzecki [06:27] zyga: hey hey [06:27] mborzecki: we should talk today [06:28] mborzecki: about how to salvage app tracking [06:33] zyga: do we need mvo for this discussion too? [06:33] mborzecki: we can split the call into more technical and more strategic parts [06:33] mborzecki: in this sense we can discuss without him [06:37] mborzecki: let's try to have a call in an hour or so [06:37] mborzecki: I have one idea for a frankenstein that might owrk [06:37] mborzecki: but it's all terrible [07:29] how can I remove this *** tracker [07:29] it spawns every few seconds logging stuff [07:30] zyga: what tracker? [07:30] Started Tracker metadata database store and lookup manager. [07:30] this shows up every few seconds [07:30] it is a systemd unit in the user session [07:30] tried disabling it [07:30] doesn't hel [07:30] help [07:30] disabled search in gnome [07:30] removing it would remove half of ubuntu [07:31] zyga: try the tracker command, `tracker daemon ` iirc [07:31] hm didn't know it's already hooked up as user service [07:32] thanks, let's see if that helps [07:59] * zyga break === pstolowski|afk is now known as pstolowski [08:10] morning [08:19] pstolowski: mvo: hey [08:19] mvo: https://github.com/snapcore/snapd/pull/7665 is green [08:19] PR #7665: devicestate: add support for gadget->gadget remodel [08:20] mborzecki: yes, I just looked at this and thats great [08:20] it just needs a second review [08:22] pstolowski: do you think you could have a look at 7665 ? [08:22] mvo: sure [08:24] thank you :) [08:25] pstolowski: thanks! [08:25] mvo: in #7715 there's a check whether a base/kernel needsInstall, and otherwise it's just adding task set with link snap task, do you think we need to do the same for gadget snap? [08:25] PR #7715: overlord: add base->base remodel undo tests and fixes [08:27] mborzecki: its done this way so that the bootloader is updatd [08:27] mborzecki: link-snap is a bit overkill actually, all we really need there is just "set-next-boot" [08:28] mborzecki: we may want something similar for gadget but its much less important, for bases its quite common to go e.g. core18->core20 but having core20 already installed because its used by some app snaps [08:29] mvo: ok, so maybe there's a case missing after all, iirc snapstate.Install() errors out if the snap is already installed, so a remodel back to the old one when the old gadget snap is still around could fail? [08:34] mborzecki: correct [08:34] mborzecki: I think this is not terrible, a followup is ifne [08:34] mvo: rigth, so land 7665, 7715 and then a followup using some code from 7715 [08:34] mborzecki: its really a corner case [08:34] mborzecki: correct [08:34] mvo: sgtm [08:34] mborzecki: cool === arnatious_ is now known as arnatious [09:08] re [09:10] zyga: feeling better today? [09:10] Chipaca: I'll feel good if we can make the feature work [09:10] Chipaca: last evening was grim [09:10] but some light at the end of the tunnel [09:10] zyga: imagine if you'd found out after implementing the whole thing [09:14] Chipaca: and merging to master ;) [09:16] mborzecki: and then steal it again! [09:17] wait no that's https://www.youtube.com/watch?v=ALZZx1xmAzg [09:25] hahah [09:28] man lubuntu is *fast* [09:42] PR snapd#7547 closed: many: use a dedicated named cgroup hierarchy for tracking <⛔ Blocked> [09:45] mvo: can you cherry-pick to 5995e03cf8b2e34ef4327a6419922fe49d41332f ? [09:45] mvo: to 2.42 ofc :) [09:48] mvo: looks like we're missing the release artifacts for 2.42.1 [09:53] mborzecki: oh, right, let me fix that [09:53] mborzecki: cherry-picked :) [09:53] mvo: thanks! [10:03] mborzecki: published, sorry for that [10:03] mvo: np, i can update the arch and fedora packges now [10:05] ta [10:10] need to run an errand, back online in 40 or so [10:17] * Chipaca not feeling too good today [10:17] take care Chipaca [10:17] i am :) thanks [10:18] * dot-tobias waves [10:22] eh, might as well do this mandatory training now [10:24] mvo: I discussed ideas with mborzecki [10:29] zyga: nice [10:29] mvo: the idea is to use a sub-directory of whatever cgroup is assigned by systemd [10:29] PR snapd#7659 closed: snap/snapenv: preserve XDG_RUNTIME_DIR for classic confinement [10:31] zyga: oh, that will work? [10:31] mvo: not for notification, but we can scan /proc and find out what we need in a loop [10:32] zyga: wrt xdg thing, ask also for non-issue [10:32] zyga: otherwise nobody trying it, and everybody trying it and finding no issues, looks the same :) [10:32] Chipaca: pardon, I don't follow [10:32] Chipaca: ah [10:32] I see [10:32] +1 [10:32] good idea [10:35] my mind is blank but I'll do my best to implement it [10:35] it's more likely to succeed than the idea from last evening === seb128_ is now known as seb128 [11:07] re [11:09] pstolowski: thanks for the review, i'll be addressing your comments shortly [11:10] mborzecki: np, ping me for re-review [11:13] mvo: can you also cherry pick 08397513608150c6fd796ceb974557c0e19d6085 to 2.42? [11:15] mborzecki: yes, done [11:15] mborzecki: thank you! [11:16] pstolowski: thanks for the review of 7665! [11:18] zyga, hrm ... we should really have some kind of interface to allow this ... coyping files to home first is very annoying [11:18] yw [11:18] mvo: cool, thanks! [11:19] ogra: it'd be somewhat tricky to make since there's a bunch of special code to make sure you cannot read /home/*/snap/ using home [11:21] i mean, it is the first time i hit this and i can probably mke the arduino ide store to home but it kind of hinders productivity since snaps typically point to ~/snap/snapname/current for their default paths ... and i can imagine a lot of use cases where one snap uses data created by another [11:23] (i.e. creating graphics with the gimp snap that i want to use in a libreoffice presentation with the libreoffice snap ... forcing people to copy around the world for that wont really make us freinds among users :) ) [11:23] zyga, mvo, jdstrand: Re: https://github.com/snapcore/snapd/pull/7655 → Thanks for the 2.42.1 candidate, I tested my snap against the new version. Does the change also cover the post-refresh hook? When I run the code that requires the Introspectable interface from a plugged app, it works fine now. But when the same code is run during post-refresh, I still get the same AppArmor denial. network-manager is plugged in top-level > hooks > [11:23] post-refresh > plugs, and I also added a top-level “plugs” dict with `network-manager: {}` to no avail. Holding it wrong? [11:23] PR #7655: interfaces: allow introspecting network-manager on core [11:24] dot-tobias: can you check the generated apparmor profile in /var/lib/snapd/apparmor/profiles/snap.$SNAP_NAME.hooks.post-refresh [11:24] and see if it has the introspection chunk [11:24] dot-tobias: I don't recall cherry-picking anything for post-refresh, its probably in edge only. if you tell me a git rev I can cherry pick in case we do a 2.42.2 [11:25] mvo: it wasn't for post refresh, it was for network-manager introspection on dbus [11:25] dot-tobias: otherwise in the next stable release in ~4 weeks [11:25] mvo: I could find the patch number if you want [11:25] zyga: aha, sry, in any case, if anything needs cherry picking please let me know but only if its really important [11:25] mvo: 5bc7682f2ef572f074dd0764015358cbe139d35d [11:25] dot-tobias: note that it was made to only affect core [11:26] aha, right [11:26] thanks [11:26] well, if its really important I can cherry pick, otherwise its in 2.43 (its not clear we do a 2.42.2 at this point) [11:26] I didn't check if that's in a point release [11:26] pstolowski: while in the remodel review swing, maybe you can have a look at 7715? [11:27] I think it might but please check what's in the apparmor profile I mentioned first [11:27] pstolowski: it should be very similar in style to the gadget one you just reviewed :) [11:30] mvo: sure, will do [11:31] zyga: https://paste.ubuntu.com/p/yJbVPHnXsX/ → apparmor profile seems to contain the necessary chunk for post-refresh. Note this is after I refreshed the snap from a local unsquashed FS via `snap try`, which had the part of its post-refresh hook disabled where Introspectable would be called. [11:31] dot-tobias: please don't use snap try for refresh-related hooks [11:32] they don't operate correctly [11:32] because snapd is confused by "before" and "after" being the same revision [11:33] zyga: Testing on a Core device. Oh ok, would it suffice if I reset the snap to an older revision and then `snap try` the newer revision with the patched post-refresh hook? The older revision doesn't plug network-manager for the hook, so I don't know how to test otherwise. [11:33] dot-tobias: I think using snap try in testing the refresh hook is not useful [11:33] just snap pack the new version [11:34] zyga: And then refresh from this local .snap file? [11:35] correct [11:35] Will test, brb [11:41] zyga: Nope, still the same AppArmor denial. I packed the modified version (changed meta/snap.yaml to include a top-level plug `network-manager: {}` and incremented version number) + installed via snap install. Relevant log entry: https://paste.ubuntu.com/p/HjC6pjcb8K/ [11:42] dot-tobias: can you look at journalctl [11:42] dot-tobias: perhaps we run the hook before the profile of network-manager is updated? [11:44] dot-tobias: if so that would be a separate bug, which would be unfortunate [11:46] zyga: What should I look for in journalctl specifically? When I search for the AppArmor denial, the lines above indicate that the network-manager profile *is* updated before: `Nov 05 12:37:29 localhost kernel: audit: type=1400 audit(1572953849.274:306): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="snap.network-manager.networkmanager" pid=14712 comm="apparmor_parser"` [11:46] (same for the other network-manager 3 profiles) [11:57] zyga: So … I checked the AppArmor profile for NetworkManager itself and it seems that even if I plug network-manager for my post-refresh hook, the profile doesn't seem to be updated. I'll open a forum thread about this. [11:57] dot-tobias: re [11:57] sorry, watching some internal HR stuff [11:58] dot-tobias: so in journal - look at the *order* for the events where apparmor_parser is invoked [11:58] for the hook [11:58] and for the network-manager service [11:58] ok [11:58] looking [11:58] it's interesting because it says "same as current" [11:59] perhaps the bug is not fixed afer all [11:59] because network manager ought to get the permission to receive it [12:00] no worries, appreciate all the help from your side 😊 [12:01] zyga: ^ and: I'm double-checking if I made a mistake, but what trips me up is that the Introspectable access works fine once my snap is refreshed (which only works when I disable the NM-related parts of my post-refresh hook, ofc). [12:01] dot-tobias: review the patch I sent for fixing this and check if there is anything that looks wrong [12:01] it should be symmetric [12:06] zyga: You mean the two snippets in https://github.com/snapcore/snapd/pull/7655/files#diff-323f555eb7f1a661aaa0bea83295e4f1R297 right? I'm writing up my test procedure and results, brb [12:06] PR #7655: interfaces: allow introspecting network-manager on core [12:06] yes [12:08] Chipaca: hey, what's the status of https://bugs.launchpad.net/snapd/+bug/1660970 ? [12:08] Bug #1660970: snap info could autocomplete against installed snaps [12:09] pstolowski: still in progress: snap run doesn't complete yet [12:10] pstolowski: I've got it tagged to reply in more detail when i can [12:10] pstolowski: (from zyga asking me( [12:10] )) [12:11] Chipaca: great, thanks [12:25] Chipaca: there is one other bug where zyga asked you for a status - https://bugs.launchpad.net/snapd/+bug/1750527 [12:25] Bug #1750527: dashboard does not validate text fields [12:30] pstolowski: yep, also tagged [12:30] 👍 [12:33] zyga: https://paste.ubuntu.com/p/pq29pv6zK8/ → It seems to me that your hunch is right: the NetworkManager slot rule is not updated for the post-refresh hook [12:33] dot-tobias: that's interesting, if you disable and enable n-m (via snap disable/enable) [12:33] if so that's a serious bug [12:34] pstolowski: also the ellipsis in utf8 one [12:35] and the snapd on 1804 proxy settings one [12:35] mborzecki: question on the idea [12:35] mborzecki: can we use the unified hierarchy in v1 [12:35] zyga: snap disable n-m / enable n-m shows no change to the Introspectable chunks … (don't know if *that* is the serious bug or if it would update 😉 ) [12:35] dot-tobias: that's not bad then, it's a regular bug then [12:35] dot-tobias: we should check why there's no snippet there though [12:35] one second please [12:36] sure [12:36] mborzecki: the logic I have so far looks for non-v2 cgroup hierarchy that has name=systemd [12:36] mborzecki: but also supports the v2 nameless, controllerless one [12:36] but this other choice, id=0 one is always present as /sys/fs/cgroup/unified in v1 world [12:36] and we can put processes there [12:37] so... perhaps that's consistency? [12:37] (after all?) [12:41] zyga: id=0 (i.e. 0::/some/path) is actually v2 hierarchy [12:41] I know [12:41] zyga: so yeah, we can do it ;) [12:41] that's why I menitoned id [12:41] yeah [12:41] I will go for it [12:41] it's consistent and easier [12:41] and actually [12:42] zyga: double check on 14.04 if we still care [12:42] I don't know how to make use of the ID otherwise [12:42] the only other piece that references it is /proc/cgroups [12:42] zyga: 0 is reserved for v2 anywya [12:42] but from there it's hard to match to /proc/self/mountinfo [12:42] unless I need to match the ID to controller [12:42] and then consider anything with that controller viable [12:42] but I don't see any supporting evidence in the documentation [12:42] I will check 14.04 before proceeding [12:43] zyga: w8, why matching with data from /proc/self/mountinfo? [12:43] mborzecki: because you don't know where the cgroup is mounted [12:43] is might be /sys/fs/cgroup or /sys/fs/cgroup/unified [12:43] I know we can check for v1-v2 mode [12:43] but it'd be nicer if this was not so "based on assumption" [12:44] hmm, my nas is down (didn't power up after last power outage) [12:44] so my 14.04 image os off, I'll just spawn spread [12:44] zyga: duh, right [12:45] zyga: hm there's only one possible instance of v2 so just looking for mount of type cgroup2 will do [12:45] yes [12:45] that's why I want to do it [12:45] it's non-ambiguous [12:45] unlike v1 [12:45] it also has one more property [12:45] we _could_ actually use the events file [12:45] haha [12:45] though I didn't think about how deeper yet [12:45] but we could [12:45] anyway [12:45] zyga: double check on 14.04 ;) [12:45] back to checking [12:46] I wish spread had -workers 1 or something [12:46] oh well [12:46] zyga: cachio's spread does [12:46] yeah but you know [12:46] ... [12:46] I only have one spread [12:46] spread-ng ;) [12:48] zyga, https://cachio.s3.amazonaws.com/spread/spread2 [12:48] cachio: thanks! [12:48] cachio: any outlook for merging -workers 1 into spread? [12:49] zyga, you can use -workers 1 -order [12:49] to follow the specific order also [12:49] dot-tobias: let me know if you find out more please [12:49] cachio: right [12:49] zyga, there is a PR for this https://github.com/snapcore/spread/pull/79 [12:49] PR spread#79: New -workers option used to define the number of workers by system [12:50] but not reviews yet [12:50] cachio: try pinging gustavo maybe [12:50] he's really receptive when pinged IMO [12:50] mborzecki: we're good, [12:50] mborzecki: 14.04 has it and it's full of stuff already (not barren) [12:52] zyga: Will do, is there something specific I should test? Not quite sure where to start here. In any case, I'll put the tasks that post-refresh should do for my snap in a service startup; shouldn't be too much overhead to run them on each startup instead of once per refresh. [12:52] dot-tobias: I think the mystery is why n-m doesn't have the new snippet [12:52] dot-tobias: look at the patch and at the file, I don't know why it might not be present [12:52] maybe our assumptions are wrong somehow? [12:55] zyga: Slightly of my depth on this (should become my motto here …) 😄 As a starter, how is ###PLUG_SECURITY_TAGS### generated in https://github.com/snapcore/snapd/pull/7655/files#diff-323f555eb7f1a661aaa0bea83295e4f1R312 ? [12:55] PR #7655: interfaces: allow introspecting network-manager on core [12:56] dot-tobias: it's generated in the line above, hidden in the diff: https://github.com/snapcore/snapd/pull/7655/files#diff-323f555eb7f1a661aaa0bea83295e4f1L480 [12:57] that returns a string that describes the labels of all plugs connected to the slot [12:59] I'm assuming the profile for n-m is only updated if there are new rules, and if my snap's post-refresh hook is somehow not recognized by the plugAppLabelExpr helper, it won't be included there? [13:00] https://github.com/snapcore/snapd/blob/aebfc2b83d7ac3ec49ff6811ddf8bc8c4c93b92d/interfaces/builtin/utils.go#L73 → would plug.Apps() also return hooks? [13:01] dot-tobias: the profile is generated in memory and reloaded if it changes; we even reload them if they don't change for a specific reason, this is why you saw the message that profile was the same as before [13:02] dot-tobias: yes, that's correct [13:02] plug.Apps would not return hooks [13:02] perhaps that is the bug?! [13:02] that's cool [13:02] that's the bug IMO [13:03] zyga: A shy “yes … maybe??” from me 😄 [13:03] pstolowski: ^ [13:03] dot-tobias: can you add that the the existing bug or open a new one [13:03] I think it's unfortunate for you but this is should be easy to address [13:03] but on the up side, now that it is know it can be fixed, otherwise the next release would be equally buggy [13:04] dot-tobias: thank you! you nailed it [13:04] Hey, happy to help out once instead of just receiving help 😊 I'll open a new bug since this probably affects all hooks, brb [13:06] yes, I think a new bug is more appropriate [13:06] zyga: why should Apps return hooks too? [13:06] they should not [13:07] but the label ought to include hooks too [13:07] using slotAppLabelExpr is just wrong [13:07] it ought to say slotAppOrHookLabel(slot) [13:07] because why would we refuse to allow hooks to have those permissions? [13:07] zyga: That might also explain why my connect-plug-network-manager hook kept failing with similar AppArmor denials for n-m:service, even though that's the whole point of connect-plug-* hooks 😄 [13:08] oops /o\ === ricab is now known as ricab|lunch [13:08] thank you for catching that! [13:08] and I'm sorry for not writing a spread test [13:08] it would show this [13:09] mborzecki: offtopic, I learned to love #pragma once [13:09] every production toolchain supports it [13:09] and it's far less silly than the ifndef approach [13:09] no need to invent names [13:10] zyga: i see [13:11] * pstolowski school run, bbiab [13:11] zyga: No worries, you people have so much on your plate with the snap ecosystem … there's always some workflow to improve, and resources are constrained. Happy to help 😊 [13:11] dot-tobias: I'll gladly help you fix this if you want to [13:12] pstolowski: pushed fixes to https://github.com/snapcore/snapd/pull/7665 [13:12] PR #7665: devicestate: add support for gadget->gadget remodel [13:12] zyga: Very much wanted, because I'd probably overlook some helper or introduce even worse bugs 😄 [13:13] dot-tobias: expand AppLabelExpr to take a map of hooks as well [13:13] the rest is a consequence of that [13:14] adjust names of the functions to convey the fact that it is not just apps now [13:14] I think this bug is silly [13:14] it's an old design that we lifted [13:14] but buggily so [13:14] we designed it so that hooks could not have interfaces initially, not all of them [13:14] I think we never noticed when this restriction went away [13:14] that the label expression is only for apps [13:14] there's some tricky code in that function [13:14] as it tries to produce nicer output than brute force [13:15] my suggestion would be to cahng it so that it considers not hooks or apps [13:15] but just a slice of names [13:15] whatever they are [13:15] and have the names be a concatenation of app labels and hook labels [13:15] “apps” in that context are apps + services in snapcraft lingo? [13:16] dot-tobias: there are no tests for appLabelExpr so I would suggest to start with that [13:16] ok, moving back home [13:16] just create a test that checks the label for the current code [13:16] dot-tobias: yes, apps are all apps, equally [13:16] services are just certain apps [13:16] dot-tobias: there is code that tests this indirectly [13:16] zyga: Ok, I'll install go, set up snapd locally and then get back to you in a week or two 😉 [13:17] but a direct test that generates snap.pkg.*, snap.pkg.{app1,app2} and snap.pkg.app3 as output would be good [13:17] as those are all the variants the current logic handles [13:17] dot-tobias: let us know if you need help but I think this is fairly nicely scoped [13:18] dot-tobias: you can build a new function, move code over from the old function, remove the old function in stages [13:18] zyga: Will do. I have some spare time atm, so this should be a nice way to a) contribute code and b) learn something new [13:18] dot-tobias: this definitely affects lots of interfaces, just git grep AppLabelExpr [13:19] zyga: Would you recommend setting things up directly on a Ubuntu host, or can I use my main macOS env to develop? [13:19] dot-tobias: linux is strongly recommended, you will have issues as our code has many parts that only build on linux [13:19] dot-tobias: personally I use vmware fusion [13:20] dot-tobias: as for the host, any linux will do really [13:20] dot-tobias: for this sort of change at least [13:20] zyga: thought so, check. Ok, I'll start with completing the bug report 😄 [13:26] uh [13:26] found an issue [13:26] but I'll wait for maciek [13:31] zyga: ^ does this relate to the issue we discussed, or sth else? [13:31] no no [13:31] it's for the cgroup thing [13:31] 👍 [13:35] mvo: I'll run the new plan by stgraber and xnox today [13:35] maybe to avoid and learn from the last experience? [13:35] * zyga needs a break [13:35] see you all at the standup [13:53] zyga: cool, thanks for chasing this [14:04] mvo: so.... model assertions [14:05] mvo: $ snap known --remote model series=20 model="ubuntu-core-20-amd64" brand-id=canonical [14:05] xnox: in a meeting [14:05] tells me that none are found =) [14:05] xnox: right, will reply in a wee bit [14:05] who should i talk to, about making a core20 pc-kernel model? =) [14:05] ack [14:10] xnox: you can try https://paste.ubuntu.com/p/DpZ2c3y4h9/ ? [14:11]