/srv/irclogs.ubuntu.com/2019/11/05/#snappy.txt

mupPR pc-amd64-gadget#22 closed: Store changes <Created by xnox> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/22>00:35
ograhrm00:39
ograwhy does the home interface not allow me to read data produced by one snap via the other in a ~/snap/<snapname>/current/ subdir00:41
ograogra@acheron:~/snap/arduino-mhall119/current/Arduino/test$ esptool -cp /dev/ttyUSB0 -cd none -ca 0x40000 -cf test.ino.generic.bin00:41
ograproduces :00:41
ograNov 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=100000:41
ografunnily enough i can copy the file to ~/ and am allowed to open it00:42
ograi'd have thought he home interface allows this ?00:42
zygaogra: that is by design06:06
zygaSnaps cannot read each other’s data06:06
mborzeckimorning06:15
mupPR snapd#7718 closed: sandbox/seccomp: accept build ID generated by Go toolchain <Simple πŸ˜ƒ> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7718>06:16
zygahey mborzecki06:27
mborzeckizyga: hey hey06:27
zygamborzecki: we should talk today06:27
zygamborzecki: about how to salvage app tracking06:28
mborzeckizyga: do we need mvo for this discussion too?06:33
zygamborzecki: we can split the call into more technical and more strategic parts06:33
zygamborzecki: in this sense we can discuss without him06:33
zygamborzecki: let's try to have a call in an hour or so06:37
zygamborzecki: I have one idea for a frankenstein that might owrk06:37
zygamborzecki: but it's all terrible06:37
zygahow can I remove this *** tracker07:29
zygait spawns every few seconds logging stuff07:29
mborzeckizyga: what tracker?07:30
zygaStarted Tracker metadata database store and lookup manager.07:30
zygathis shows up every few seconds07:30
zygait is a systemd unit in the user session07:30
zygatried disabling it07:30
zygadoesn't hel07:30
zygahelp07:30
zygadisabled search in gnome07:30
zygaremoving it would remove half of ubuntu07:30
mborzeckizyga: try the tracker command, `tracker daemon <something>` iirc07:31
mborzeckihm didn't know it's already hooked up as user service07:31
zygathanks, let's see if that helps07:32
* zyga break07:59
=== pstolowski|afk is now known as pstolowski
pstolowskimorning08:10
mborzeckipstolowski: mvo: hey08:19
mborzeckimvo: https://github.com/snapcore/snapd/pull/7665 is green08:19
mupPR #7665:  devicestate: add support for gadget->gadget remodel  <Priority πŸ‡> <Remodel πŸš‹> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7665>08:19
mvomborzecki: yes, I just looked at this and thats great08:20
mvoit just needs a second review08:20
mvopstolowski: do you think you could have a look at 7665 ?08:22
pstolowskimvo: sure08:22
mvothank you :)08:24
mborzeckipstolowski: thanks!08:25
mborzeckimvo: 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
mupPR #7715: overlord: add base->base remodel undo tests and fixes <Priority πŸ‡> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7715>08:25
mvomborzecki: its done this way so that the bootloader is updatd08:27
mvomborzecki: link-snap is a bit overkill actually, all we really need there is just "set-next-boot"08:27
mvomborzecki: 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 snaps08:28
mborzeckimvo: 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:29
mvomborzecki: correct08:34
mvomborzecki: I think this is not terrible, a followup is ifne08:34
mborzeckimvo: rigth, so land 7665, 7715 and then a followup using some code from 771508:34
mvomborzecki: its really a corner case08:34
mvomborzecki: correct08:34
mborzeckimvo: sgtm08:34
mvomborzecki: cool08:34
=== arnatious_ is now known as arnatious
zygare09:08
Chipacazyga: feeling better today?09:10
zygaChipaca: I'll feel good if we can make the feature work09:10
zygaChipaca: last evening was grim09:10
zygabut some light at the end of the tunnel09:10
Chipacazyga: imagine if you'd found out after implementing the whole thing09:10
mborzeckiChipaca: and merging to master ;)09:14
Chipacamborzecki: and then steal it again!09:16
Chipacawait no that's https://www.youtube.com/watch?v=ALZZx1xmAzg09:17
mborzeckihahah09:25
Chipacaman lubuntu is *fast*09:28
mupPR snapd#7547 closed: many: use a dedicated named cgroup hierarchy for tracking <β›” Blocked> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/7547>09:42
mborzeckimvo:  can you cherry-pick to 5995e03cf8b2e34ef4327a6419922fe49d41332f ?09:45
mborzeckimvo: to 2.42 ofc :)09:45
mborzeckimvo: looks like we're missing the release artifacts for 2.42.109:48
mvomborzecki: oh, right, let me fix that09:53
mvomborzecki: cherry-picked :)09:53
mborzeckimvo: thanks!09:53
mvomborzecki: published, sorry for that10:03
mborzeckimvo: np, i can update the arch and fedora packges now10:03
mvota10:05
mborzeckineed to run an errand, back online in 40 or so10:10
* Chipaca not feeling too good today10:17
zygatake care Chipaca10:17
Chipacai am :) thanks10:17
* dot-tobias waves10:18
Chipacaeh, might as well do this mandatory training now10:22
zygamvo: I discussed ideas with mborzecki10:24
mvozyga: nice10:29
zygamvo: the idea is to use a sub-directory of whatever cgroup is assigned by systemd10:29
mupPR snapd#7659 closed: snap/snapenv: preserve XDG_RUNTIME_DIR for classic confinement <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7659>10:29
mvozyga: oh, that will work?10:31
zygamvo: not for notification, but we can scan /proc and find out what we need in a loop10:31
Chipacazyga: wrt xdg thing, ask also for non-issue10:32
Chipacazyga: otherwise nobody trying it, and everybody trying it and finding no issues, looks the same :)10:32
zygaChipaca: pardon, I don't follow10:32
zygaChipaca: ah10:32
zygaI see10:32
zyga+110:32
zygagood idea10:32
zygamy mind is blank but I'll do my best to implement it10:35
zygait's more likely to succeed than the idea from last evening10:35
=== seb128_ is now known as seb128
mborzeckire11:07
mborzeckipstolowski: thanks for the review, i'll be addressing your comments shortly11:09
pstolowskimborzecki: np, ping me for re-review11:10
mborzeckimvo: can you also cherry pick 08397513608150c6fd796ceb974557c0e19d6085 to 2.42?11:13
mvomborzecki: yes, done11:15
mvomborzecki: thank you!11:15
mvopstolowski: thanks for the review of 7665!11:16
ograzyga, hrm ... we should really have some kind of interface to allow this ... coyping files to home first is very annoying11:18
pstolowskiyw11:18
mborzeckimvo: cool, thanks!11:18
zygaogra: it'd be somewhat tricky to make since there's a bunch of special code to make sure you cannot read /home/*/snap/ using home11:19
ograi 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 another11:21
ogra(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
dot-tobiaszyga, 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
dot-tobias post-refresh > plugs, and I also added a top-level β€œplugs” dict with `network-manager: {}` to no avail. Holding it wrong?11:23
mupPR #7655: interfaces: allow introspecting network-manager on core <Bug> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7655>11:23
zygadot-tobias: can you check the generated apparmor profile in /var/lib/snapd/apparmor/profiles/snap.$SNAP_NAME.hooks.post-refresh11:24
zygaand see if it has the introspection chunk11:24
mvodot-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.211:24
zygamvo: it wasn't for post refresh, it was for network-manager introspection on dbus11:25
mvodot-tobias: otherwise in the next stable release in ~4 weeks11:25
zygamvo: I could find the patch number if you want11:25
mvozyga: aha, sry, in any case, if anything needs cherry picking please let me know but only if its really important11:25
zygamvo: 5bc7682f2ef572f074dd0764015358cbe139d35d11:25
zygadot-tobias: note that it was made to only affect core11:25
mvoaha, right11:26
mvothanks11:26
mvowell, 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
zygaI didn't check if that's in a point release11:26
mvopstolowski: while in the remodel review swing, maybe you can have a look at 7715?11:26
zygaI think it might but please check what's in the apparmor profile I mentioned first11:27
mvopstolowski: it should be very similar in style to the gadget one you just reviewed :)11:27
pstolowskimvo: sure, will do11:30
dot-tobiaszyga: 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
zygadot-tobias: please don't use snap try for refresh-related hooks11:31
zygathey don't operate correctly11:32
zygabecause snapd is confused by "before" and "after" being the same revision11:32
dot-tobiaszyga: 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
zygadot-tobias: I think using snap try in testing the refresh hook is not useful11:33
zygajust snap pack the new version11:33
dot-tobiaszyga: And then refresh from this local .snap file?11:34
zygacorrect11:35
dot-tobiasWill test, brb11:35
dot-tobiaszyga: 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:41
zygadot-tobias: can you look at journalctl11:42
zygadot-tobias: perhaps we run the hook before the profile of network-manager is updated?11:42
zygadot-tobias: if so that would be a separate bug, which would be unfortunate11:44
dot-tobiaszyga: 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
dot-tobias(same for the other network-manager 3 profiles)11:46
dot-tobiaszyga: 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
zygadot-tobias: re11:57
zygasorry, watching some internal HR stuff11:57
zygadot-tobias: so in journal - look at the *order* for the events where apparmor_parser is invoked11:58
zygafor the hook11:58
zygaand for the network-manager service11:58
zygaok11:58
zygalooking11:58
zygait's interesting because it says "same as current"11:58
zygaperhaps the bug is not fixed afer all11:59
zygabecause network manager ought to get the permission to receive it11:59
dot-tobiasno worries, appreciate all the help from your side 😊12:00
dot-tobiaszyga: ^ 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
zygadot-tobias: review the patch I sent for fixing this and check if there is anything that looks wrong12:01
zygait should be symmetric12:01
dot-tobiaszyga: 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, brb12:06
mupPR #7655: interfaces: allow introspecting network-manager on core <Bug> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7655>12:06
zygayes12:06
pstolowskiChipaca: hey, what's the status of https://bugs.launchpad.net/snapd/+bug/1660970 ?12:08
mupBug #1660970: snap info could autocomplete against installed snaps <snapd:In Progress by chipaca> <https://launchpad.net/bugs/1660970>12:08
Chipacapstolowski: still in progress: snap run doesn't complete yet12:09
Chipacapstolowski: I've got it tagged to reply in more detail when i can12:10
Chipacapstolowski: (from zyga asking me(12:10
Chipaca))12:10
pstolowskiChipaca: great, thanks12:11
pstolowskiChipaca: there is one other bug where zyga asked you for a status - https://bugs.launchpad.net/snapd/+bug/175052712:25
mupBug #1750527: dashboard does not validate text fields <review-tools:Fix Released by jdstrand> <Snapcraft:New> <snapd:In Progress by chipaca> <Snap Store:Fix Released by matiasb> <https://launchpad.net/bugs/1750527>12:25
Chipacapstolowski: yep, also tagged12:30
pstolowskiπŸ‘12:30
dot-tobiaszyga: 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 hook12:33
zygadot-tobias: that's interesting, if you disable and enable n-m (via snap disable/enable)12:33
zygaif so that's a serious bug12:33
Chipacapstolowski: also the ellipsis in utf8 one12:34
Chipacaand the snapd on 1804 proxy settings one12:35
zygamborzecki: question on the idea12:35
zygamborzecki: can we use the unified hierarchy in v112:35
dot-tobiaszyga: 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
zygadot-tobias: that's not bad then, it's a regular bug then12:35
zygadot-tobias: we should check why there's no snippet there though12:35
zygaone second please12:35
dot-tobiassure12:36
zygamborzecki: the logic I have so far looks for non-v2 cgroup hierarchy that has name=systemd12:36
zygamborzecki: but also supports the v2 nameless, controllerless one12:36
zygabut this other choice, id=0 one is always present as /sys/fs/cgroup/unified in v1 world12:36
zygaand we can put processes there12:36
zygaso... perhaps that's consistency?12:37
zyga(after all?)12:37
mborzeckizyga: id=0 (i.e. 0::/some/path) is actually v2 hierarchy12:41
zygaI know12:41
mborzeckizyga: so yeah, we can do it ;)12:41
zygathat's why I menitoned id12:41
zygayeah12:41
zygaI will go for it12:41
zygait's consistent and easier12:41
zygaand actually12:41
mborzeckizyga: double check on 14.04 if we still care12:42
zygaI don't know how to make use of the ID otherwise12:42
zygathe only other piece that references it is /proc/cgroups12:42
mborzeckizyga: 0 is reserved for v2 anywya12:42
zygabut from there it's hard to match to /proc/self/mountinfo12:42
zygaunless I need to match the ID to controller12:42
zygaand then consider anything with that controller viable12:42
zygabut I don't see any supporting evidence in the documentation12:42
zygaI will check 14.04 before proceeding12:42
mborzeckizyga: w8, why matching with data from /proc/self/mountinfo?12:43
zygamborzecki: because you don't know where the cgroup is mounted12:43
zygais might be /sys/fs/cgroup or /sys/fs/cgroup/unified12:43
zygaI know we can check for v1-v2 mode12:43
zygabut it'd be nicer if this was not so "based on assumption"12:43
zygahmm, my nas is down (didn't power up after last power outage)12:44
zygaso my 14.04 image os off, I'll just spawn spread12:44
mborzeckizyga: duh, right12:44
mborzeckizyga: hm there's only one possible instance of v2 so just looking for mount of type cgroup2 will do12:45
zygayes12:45
zygathat's why I want to do it12:45
zygait's non-ambiguous12:45
zygaunlike v112:45
zygait also has one more property12:45
zygawe _could_ actually use the events file12:45
mborzeckihaha12:45
zygathough I didn't think about how deeper yet12:45
zygabut we could12:45
zygaanyway12:45
mborzeckizyga: double check on 14.04 ;)12:45
zygaback to checking12:45
zygaI wish spread had -workers 1 or something12:46
zygaoh well12:46
mborzeckizyga: cachio's spread does12:46
zygayeah but you know12:46
zyga...12:46
zygaI only have one spread12:46
mborzeckispread-ng ;)12:46
cachiozyga, https://cachio.s3.amazonaws.com/spread/spread212:48
zygacachio: thanks!12:48
zygacachio: any outlook for merging -workers 1 into spread?12:48
cachiozyga, you can use -workers 1 -order12:49
cachioto follow the specific order also12:49
zygadot-tobias: let me know if you find out more please12:49
zygacachio: right12:49
cachiozyga, there is a PR for this https://github.com/snapcore/spread/pull/7912:49
mupPR spread#79: New -workers option used to define the number of workers by system <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/79>12:49
cachiobut not reviews yet12:50
zygacachio: try pinging gustavo maybe12:50
zygahe's really receptive when pinged IMO12:50
zygamborzecki: we're good,12:50
zygamborzecki: 14.04 has it and it's full of stuff already (not barren)12:50
dot-tobiaszyga: 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
zygadot-tobias: I think the mystery is why n-m doesn't have the new snippet12:52
zygadot-tobias: look at the patch and at the file, I don't know why it might not be present12:52
zygamaybe our assumptions are wrong somehow?12:52
dot-tobiaszyga: 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
mupPR #7655: interfaces: allow introspecting network-manager on core <Bug> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7655>12:55
zygadot-tobias: it's generated in the line above, hidden in the diff: https://github.com/snapcore/snapd/pull/7655/files#diff-323f555eb7f1a661aaa0bea83295e4f1L48012:56
zygathat returns a string that describes the labels of all plugs connected to the slot12:57
dot-tobiasI'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?12:59
dot-tobiashttps://github.com/snapcore/snapd/blob/aebfc2b83d7ac3ec49ff6811ddf8bc8c4c93b92d/interfaces/builtin/utils.go#L73 β†’ would plug.Apps() also return hooks?13:00
zygadot-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 before13:01
zygadot-tobias: yes, that's correct13:02
zygaplug.Apps would not return hooks13:02
zygaperhaps that is the bug?!13:02
zygathat's cool13:02
zygathat's the bug IMO13:02
dot-tobiaszyga: A shy β€œyes … maybe??” from me πŸ˜„13:03
zygapstolowski: ^13:03
zygadot-tobias: can you add that the the existing bug or open a new one13:03
zygaI think it's unfortunate for you but this is should be easy to address13:03
zygabut on the up side, now that it is know it can be fixed, otherwise the next release would be equally buggy13:03
zygadot-tobias: thank you! you nailed it13:04
dot-tobiasHey, happy to help out once instead of just receiving help 😊 I'll open a new bug since this probably affects all hooks, brb13:04
zygayes, I think a new bug is more appropriate13:06
pstolowskizyga: why should Apps return hooks too?13:06
zygathey should not13:06
zygabut the label ought to include hooks too13:07
zygausing slotAppLabelExpr is just wrong13:07
zygait ought to say slotAppOrHookLabel(slot)13:07
zygabecause why would we refuse to allow hooks to have those permissions?13:07
dot-tobiaszyga: 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:07
zygaoops /o\13:08
=== ricab is now known as ricab|lunch
zygathank you for catching that!13:08
zygaand I'm sorry for not writing a spread test13:08
zygait would show this13:08
zygamborzecki: offtopic, I learned to love #pragma once13:09
zygaevery production toolchain supports it13:09
zygaand it's far less silly than the ifndef approach13:09
zygano need to invent names13:09
pstolowskizyga: i see13:10
* pstolowski school run, bbiab13:11
dot-tobiaszyga: 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
zygadot-tobias: I'll gladly help you fix this if you want to13:11
mborzeckipstolowski: pushed fixes to https://github.com/snapcore/snapd/pull/766513:12
mupPR #7665:  devicestate: add support for gadget->gadget remodel  <Priority πŸ‡> <Remodel πŸš‹> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7665>13:12
dot-tobiaszyga: Very much wanted, because I'd probably overlook some helper or introduce even worse bugs πŸ˜„13:12
zygadot-tobias: expand AppLabelExpr to take a map of hooks as well13:13
zygathe rest is a consequence of that13:13
zygaadjust names of the functions to convey the fact that it is not just apps now13:14
zygaI think this bug is silly13:14
zygait's an old design that we lifted13:14
zygabut buggily so13:14
zygawe designed it so that hooks could not have interfaces initially, not all of them13:14
zygaI think we never noticed when this restriction went away13:14
zygathat the label expression is only for apps13:14
zygathere's some tricky code in that function13:14
zygaas it tries to produce nicer output than brute force13:14
zygamy suggestion would be to cahng it so that it considers not hooks or apps13:15
zygabut just a slice of names13:15
zygawhatever they are13:15
zygaand have the names be a concatenation of app labels and hook labels13:15
dot-tobiasβ€œapps” in that context are apps + services in snapcraft lingo?13:15
zygadot-tobias: there are no tests for appLabelExpr so I would suggest to start with that13:16
mborzeckiok, moving back home13:16
zygajust create a test that checks the label for the current code13:16
zygadot-tobias: yes, apps are all apps, equally13:16
zygaservices are just certain apps13:16
zygadot-tobias: there is code that tests this indirectly13:16
dot-tobiaszyga: Ok, I'll install go, set up snapd locally and then get back to you in a week or two πŸ˜‰13:16
zygabut a direct test that generates snap.pkg.*, snap.pkg.{app1,app2} and snap.pkg.app3 as output would be good13:17
zygaas those are all the variants the current logic handles13:17
zygadot-tobias: let us know if you need help but I think this is fairly nicely scoped13:17
zygadot-tobias: you can build a new function, move code over from the old function, remove the old function in stages13:18
dot-tobiaszyga: Will do. I have some spare time atm, so this should be a nice way to a) contribute code and b) learn something new13:18
zygadot-tobias: this definitely affects lots of interfaces, just git grep AppLabelExpr13:18
dot-tobiaszyga: Would you recommend setting things up directly on a Ubuntu host, or can I use my main macOS env to develop?13:19
zygadot-tobias: linux is strongly recommended, you will have issues as our code has many parts that only build on linux13:19
zygadot-tobias: personally I use vmware fusion13:19
zygadot-tobias: as for the host, any linux will do really13:20
zygadot-tobias: for this sort of change at least13:20
dot-tobiaszyga: thought so, check. Ok, I'll start with completing the bug report πŸ˜„13:20
zygauh13:26
zygafound an issue13:26
zygabut I'll wait for maciek13:26
dot-tobiaszyga: ^ does this relate to the issue we discussed, or sth else?13:31
zygano no13:31
zygait's for the cgroup thing13:31
dot-tobiasπŸ‘13:31
zygamvo: I'll run the new plan by stgraber and xnox today13:35
zygamaybe to avoid and learn from the last experience?13:35
* zyga needs a break13:35
zygasee you all at the standup13:35
mvozyga: cool, thanks for chasing this13:53
xnoxmvo:  so.... model assertions14:04
xnoxmvo:  $ snap known --remote model series=20 model="ubuntu-core-20-amd64" brand-id=canonical14:05
mvoxnox: in a meeting14:05
xnoxtells me that none are found =)14:05
mvoxnox: right, will reply in a wee bit14:05
xnoxwho should i talk to, about making a core20 pc-kernel model? =)14:05
xnoxack14:05
mvoxnox: you can try https://paste.ubuntu.com/p/DpZ2c3y4h9/ ?14:10
mvoxnox: its "my" model, not the canocnial one yet14:11
mvoxnox: but I get error: cannot use gadget snap because its base "" is different from model base "core20" with that so I need to look14:11
mvoxnox: either pc is not quite right (the snap) or something else, haven't had time yet to dig (meeting)14:11
xnoxmvo:  why is it series=16?14:28
mvoxnox: loooooong story14:28
xnoxmvo:  would be nice to be series 20 and make that the default track14:28
xnoxmvo:  why is there no snapd snap listed?14:29
mvoxnox: the "series" is about the "format" of the entire architecture of snaps14:29
xnoxmvo:  how does one specify to use "edge"?14:29
mvoxnox: its implicit, I guess we could/should make it explicit though14:29
mvoxnox: ubuntu-image --channel=edge14:29
mvoxnox: that should work14:29
xnoxok14:29
mvoxnox: I got further, my image creation is now exploding that "dangerous" is not yet supported14:30
xnoxmvo:  how does one create model assertions?14:30
* xnox wants to play with this stuff14:30
xnoxmvo:  also do we have git models committed anywhere? or is it simply in the store?14:30
mvoxnox: use https://paste.ubuntu.com/p/VfkNwGQCHK/ as input, modify brand-id and then run snap sign14:31
xnoxmvo:  ack14:31
mvoxnox: there is a doc that describes this, still in a meeting so can give you only 15% of my attention14:31
* xnox ponders to commit them into the pc gadget git repo, on respective branches14:31
=== ricab|lunch is now known as ricab
xnoxi am confused what are the magic values of like authority-id brand-id id14:37
mvoxnox: its in your account page14:38
xnoxack14:38
mvoxnox: meeting over, now you can have more attention :)14:38
mvoxnox: https://dashboard.snapcraft.io/dev/account/14:38
mvoxnox: there is the accound-id there14:38
mvoxnox: use that for brandh-id, authority-id14:39
xnoxmvo:  ok, and ids on snaps? is that the unique ids of the snaps, in addition to just their name?14:40
Chipacaxnox: snap info --verbose will show you the snap id14:40
mvoxnox: correct, snap info --verbose <name> will give you those14:40
xnoxmvo:  can timestamp be in the future? we should set it to 2020-04-23T20:04:00:00.0Z14:42
mvoxnox: not sure that this will work14:42
xnoxmvo:  because you think hardware clocks have real time?! that's just silly.14:43
xnoxmvo:  grade dangerous is invalid, no? it's called "devel"14:45
mvoxnox: that sounds slightly outdated, let me try to find where this was written down but I can point you to the code. its "unset", "secured", "signed" and "dangerous" there14:53
xnoxmvo:  i find it extremly odd to use key "grade" in both model & snapcraft, with widely different meaning and values.14:53
mvoxnox: https://github.com/snapcore/snapd/blob/master/asserts/model.go#L32014:54
mvoxnox: right, unfortunately samuele is on vac, that's a topic for him14:54
xnoxmvo:  then it should be called like model-grade, not just grade =/14:54
xnoxmvo:  imho we should be able to build "signed" one today, no need for "dangerous"14:56
mvoxnox: yeah, if you feel strongly, please mail samuele to discuss this, I don't think its set in stone but it will get harder to change the closer we get :)14:56
xnoxmvo:  also, this implies we will have two models, and two images for core20 => with and without tpm-fde? but current working assumption is that a single image can be both.14:57
xnoxi.e. "signed" should be allowed to be "secured", wheres as "secured" should not be. Ie. "signed" should be a superset of "secured", and ditto "signed" and "dangerous" should be supersets of previous one.14:58
xnoxi.e. it's totally fine to have "dangerous" one effectively running as "secured" if all pieces work.14:58
mvoxnox: dangerous can still have fde, it just allows to sideload stuff, or am I misunderstanding?14:59
mvoxnox: also, my next meeting starts now ./ so back to 15% of my attention for you14:59
mvoxnox: sorry!14:59
roadmrETOOMANYMEETINGS? πŸ€”15:02
xnoxsnap sign cannot do GPG it seems.... it cannot find a key named "default" wtf?!15:05
* xnox uses a smartcard15:05
mborzeck1cmatsuoka: some comments under #768715:09
mupPR #7687: snap-bootstrap: check gadget versus disk partitions <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7687>15:09
kjackalhey snappy people, in a classic snap, when I use sudo, should i use the "sudo" binary of core?15:11
xnoxkjackal:  you should simply use sudo, with PATH discovery. ie. just "sudo" not any absolute path.15:14
kjackalI see MicroK8s in Centos 8.0 and fedora 29 failing when using sudo and I am wondering if I should package sudo or use the host's, or use the core's15:14
xnoxnote sudo is not universal, and is not guaranteed to be installed, or usable.15:14
xnoxone might be root already, then no sudo should be needed, etc.15:15
kjackalxnox: this is the error I am getting https://forum.snapcraft.io/t/pam-account-management-error/1402615:15
xnoxkjackal:  some of it, looks like a broken core snap15:16
kjackalin my case sudo is available but the libraries are not in the right places (?)15:16
xnoxor rather mixed up LD configuration / overrides / preloads, ie. system pam is used with libraries from a core snap, which will never work =)15:17
xnoxkjackal:  i wonder if environment that snap setup for you, is interfering with using system PAM session correctly15:18
zygaBack home now15:18
kjackalxnox: I am setting some env variables here: https://github.com/ubuntu/microk8s/blob/master/microk8s-resources/wrappers/microk8s-enable.wrapper#L4 could these be a problem?15:20
* cachio afk15:20
* cachio lunch15:20
xnoxkjackal:  yes, all of them.15:32
xnoxkjackal:  these are good, for using binaries from inside the snap, but bad if one tries to dlopen system installed ones (like pam does for pam modules which dlopen things)15:32
kjackalxnox: but i am doing for example "sudo <something_in_my_snap>" so... ?15:33
xnoxkjackal:  which is operating sudo itself with those environment variables in effect. which is bombing out.15:34
xnoxbecause sudo, tries to open a pam session, as per system wide config, loads pam modules from the system-wide, yet with LD_ path pointing inside the snap which is incompatible with with system-wide libraries15:35
xnoxkjackal:  store and export original path, ie. with export STOCK_PATH=$PATH ditto for STOCK LD_LIBRARY_PATH15:36
xnoxkjackal:  and i expect something like this will work:15:36
xnoxPATH=$STOCK_PATH LD_LIBRARY_PATH=$STOCK_LD_LIBRARY_PATH sudo PATH=$PATH LD_LIBRARY_PATH=$LD_LIBRARY_PATH sed -i15:36
xnoxkjackal:  ie. use system wide sudo, with system-wide PATH & LD_LIBRARY_PATH, but use snap paths for sed.15:37
xnoxalthough imho one can rely on system sed too, as it's fundamental too.15:37
xnoxalthough imho one can rely on system sed too, as it's fundamental tool.15:37
kjackalI see, will try that15:37
kjackalthank you xnox15:38
xnoxkjackal:  your problem is that one cannot really create and use pam session from inside a snap, and expect it to work with the system-wide pam config. Meaning one has to use system-wide sudo15:38
xnoxbecause all of those things use absolute paths to dlopen() libraries which all must match.15:38
xnoxit "works" by magic on like Ubuntu due to e.g. snap build on xenial, and libraries staying compatible for basic things like that15:39
xnox(i.e. when host == snap abi's by accident)15:39
xnoxkjackal:  also note that i have no idea what i'm talking about and i'm jsut a random person on irc who has zero idea about how snaps work =)15:40
kjackal:)15:41
=== mborzeck1 is now known as mborzecki
mborzeckisnapd in AUR has been updated to 2.42.115:43
* mvo hugs mborzecki 15:43
pstolowskispread tests in #7715 and #7665 are very alike, i'm not sure who was first ;) fwtw i'm adding same comments ;)15:47
mupPR #7715: overlord: add base->base remodel undo tests and fixes <Priority πŸ‡> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7715>15:47
mupPR #7665:  devicestate: add support for gadget->gadget remodel  <Priority πŸ‡> <Remodel πŸš‹> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7665>15:47
xnoxmvo:  error: cannot override channels, add local snaps or extra snaps with a model of grade higher than dangerous15:51
xnoxmvo:  hm..... prepare-image fails..... but i'm confused about these constraints. How do I build image of a model, using edge channels? model doesn't allow to specify channel does it?15:52
mvoxnox: yeah, I hit this too, I'm looking into it15:52
mvoxnox: basicly we need to land one more PR (771215:52
mvoxnox: then we can have a "grade: dangerous" model that allows overriding15:53
mvoxnox: I was also looking into: https://paste.ubuntu.com/p/5bhBPMvVJj/15:53
mvoxnox: but that fails with a strange error, that it can't find core20 which I think is a lie15:53
pstolowskimvo: reviewed #771515:54
mupPR #7715: overlord: add base->base remodel undo tests and fixes <Priority πŸ‡> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7715>15:54
xnoxmvo:  hm.... i'm not sure if that's what i am hitting..... because all the snaps i'm using are acked and in store. I'm not using any unsigned, or unasserted snaps15:54
mvoxnox: you did specify --channel=edge, maybe?15:55
mvopstolowski: cool, will look15:55
* mvo needs to taxi kids around for ~30min15:55
mvobbiab15:55
xnoxfor me it's fetching the wrong gadget snap!15:57
zygare again15:58
* zyga had dinner and an unexpected encounter15:58
zygamy neighbor was venting old stuff and asked me if ... I want any of his 90s games collection15:59
zygaso now I have a CD-ROM with dungeon master 215:59
zygaand a few similar games15:59
zygaanyway15:59
zygaback to work15:59
zygaxnox: hey15:59
zygaxnox: we have an idea and before pursuing further wanted to ask you for advice16:00
zygaxnox: it is related to systemd and cgroups16:00
zygaxnox: the idea is: when snaps are invoked they put themselves into a new leaf under wherever systemd had placed them16:00
zygaxnox: in the unified v2 hierarchy16:00
zygaxnox: so for example, on /user.slice/user-1000.slice/user@100.service/snap.pkg.app16:01
zygaxnox: or something equally appropriate for system services16:01
zygaxnox: we'd be stealing the process from systemd16:01
zygaxnox: but placing it deeper in the same hierarchy16:01
zygaxnox: casual testing shows that systemd is not confused and still manages services correctly16:02
zygaxnox: we intend to use the unified hierarchy in v2 mode, obviously, because we have no other choice16:03
zygaxnox: but also in the v1 mode16:03
zygaxnox: because it is seemingly working the same way for what we intend (associating PIDs with snaps)16:03
xnoxso i have this https://bugs.launchpad.net/snapd/+bug/185140116:04
mupBug #1851401: snap prepare-image downloads wrong snaps <snapd:New> <https://launchpad.net/bugs/1851401>16:04
xnoxzyga:  "when snaps are invoked they put themselves into a new leaf under wherever systemd had placed them"  using children, and further scoping is always safe. Moving "up" is usually either not-allowed, or is a priviledged operation. Systemd should not get confused, as long as you don't change notification agents on it. And yes it should be fine under v1/v2/hybrid. BTW why do you want to do this?16:07
xnoxi.e. what are you trying to solve?16:07
zygaxnox: that's good news16:07
zygaxnox: we want this to implement a feature where snapd pauses refreshes while an app is open16:07
xnoxthat's insecure and abusable.16:08
zygaxnox: and can, having tried to refresh but deciding not to16:08
xnoxas unpriviledged user can create those cgroups and put arbitrary processes into them.16:08
zygaxnox: then decide to refresh it reasonably fast after it was closed16:08
zygaxnox: that's ok, we have safeguards for that16:08
zygaxnox: that is, firefox running forever in a snap will eventually referesh anyway16:08
zyga*refresh16:08
xnoxi.e. you could make binaries be "systemd-run actual binary" cause then pid1 will put the process into a system cgroup, which is authoritative.16:09
zygaxnox: we considered that but we don't have systemd-run across all versions we support16:09
zygaxnox: but it's also a problem there16:10
zygaxnox: because we want to have this available uniformly across all apps16:10
zygaxnox: including services16:10
zygaxnox: and using systemd-run from inside what is effectively a service file with Exec line16:10
xnoxzyga:  you do have sytemd-run everywhere.... given that it's in core1616:11
zygaxnox: we are at the mercy of what systemd allows us to do here sadly, as snaps need to integrate with existing system services and be managed by systemd directly16:11
xnoxzyga:  you don't need systemd-run for services, as pid1 already placed them into an authoritative cgroup16:11
zygaxnox: I think we don't have that on 14.0416:11
zygaxnox: but even then the other problem is more severe16:11
zygaxnox: "apache", "firefox" and "grep" type workloads need to be supported in this mode16:11
xnoxzyga:  systemd-run is inside core snap, and on 14.04 it runs against subordinate systemd which has it.....16:11
zygaxnox: I see but core is not mandatory and it would also complicate startup, what if you install a snap with bare base on 14.04?16:12
xnoxzyga:  if you only do this for "user" apps, that's fine. I.e. i don't want to hold up daemon refreshes, due to unpriviledged user controlled cgroups.16:12
zygaxnox: we want this to work uniformly for all applications but there's some smarts for services16:13
xnoxi.e. somebody executing "snap --help" and freezing it, should not prevent snapd refresh for example16:13
zygaxnox: snap --help won't prevent snapd from refreshing16:13
xnoxzyga:  it's insecure, thus you must have security team review / signoff on this logic.16:13
zygaxnox: can you specify what is insecure specifically16:14
zygaxnox: (we always get security review for features like that)16:14
xnoxzyga: arbittrary users can create the cgroups like /user.slice/user-1000.slice/user@100.service/snap.pkg.app which have never been executed via snap/snapd16:14
xnoxwith zombie /bin/true process16:15
zygaindeed, this is true16:15
zygaxnox: at this point we ran out of ideas for things that work across the stack unfortunately16:15
xnoxyou could use kernel keyrign to list snap invocation_ids which is read only, to then lock that up. Cause that's what e.g. systemd-run does16:16
zygaxnox: users don't have to be nasty, they can just run the real app16:16
zygaxnox: so it is not a new problem of the feature16:16
xnoxzyga:  also i challenge you on the 14.04 assertion, i believe systemd-run is available there.16:16
zygaxnox: invocation IDs?16:16
xnoxsystemd creates process keyring and puts a unique key there and makes it readonly and exports it as an evironment variable. Then processes can share that keyring (ie. group of services) and then they can all know that they are part of the same "reexec" for example. Kind of like a cohort key.16:17
xnoxbut with kernel protection that nobody can modify or fake it16:18
zygaxnox: interesting, which syscalls govern that? I'll read about it16:18
zygaxnox: and do you know if this will work inside LXD16:18
zygaxnox: as whatever we need to do needs to work in lxd across the stack16:18
xnoxit does work in lxd today, but i don't remeber when it was added.16:18
zyga(we are in this situation after we realized mounting a v1 name=snapd cgroup doesn't work)16:18
xnoxzyga:  why do you care about 14.04?16:18
zygaxnox: it's still supported, we cannot abandon it without some official kick16:19
zygaxnox: but I would not hold onto 14.0416:19
zygaxnox: it's just that systemd-run doesn't do what we want to AFAIK16:19
xnoxzyga:  it's passed end of basic support, and excludes support for snapd in ESM16:19
zygaxnox: unless I misunderstand16:19
xnoxzyga:  it's dead to you16:19
xnoxand i.e. subordinate systemd is not supported there for sure.16:20
zygaxnox: I need mvo to tell me that, I asked recently and I got a different answer16:20
xnoxmvo16:20
xnoxnot in this channel16:20
zygait seems he is not connected now16:20
zygaxnox: but even assuming we can run systemd-run16:20
zygaxnox: can you outline how we could use that to identify all snap execution entry points?16:20
zygathat is, all apps, hooks and services16:21
zygaso that when scanning PIDs16:21
zygawe can see where they came from16:21
xnoxzyga:  and 14.04 is very unconfined, as far as i understand. i.e. most interesting interfaces are not supported on 14.04 anyway.16:21
zygaxnox: I think actually only fuse is not, everything else is not special cased on 14.0416:21
zygait's not supported for desktop apps but that is all16:21
xnoxvorlon:  what's status of supporting snapd on 14.04? i thought it's dead and not part of ESM.16:22
zygaxnox: so would snap-run invoke systemd-run which would invoke snap-confine and then snap-exec?16:23
vorlonxnox: I don't know why you had that impression; you should look to the Security Team for a specific support statement, but I'd be surprised if snapd wasn't in scope16:23
zygaI suspect that the nature of ESM is that it's too soon to say something is not supported16:23
zygathe policy in snapd team, for now, as far as I know, is that 14.04 is still a target16:24
xnoxzyga:  imho that call chain "makes sense" but potentially breaks a lot of desktop integration, unless one is careful to do --user / --system for the systemd-run bit.16:24
zygaand we are not introducing features that don't support it16:24
zygaxnox: can you walk me through the operations of systemd-run, what do we get by using it and how should we invoke it?16:25
xnoxzyga:  i'm very busy, and i've spend too much time talking to you already. So no, i don't. plese read man pages for systemd-run, they have a lot of details.16:25
zygaxnox: I will, thank you for the advice and for the discussion, it's very useful16:26
zygaxnox: I don't think we can use systemd-run16:27
zygaxnox: based on the man page itself16:27
xnoxvorlon:  zyga: snapd is explicitely called out as an exclusion for 14.04 ESM that's where i got this impression from https://wiki.ubuntu.com/SecurityTeam/ESM/14.04#Exclusions16:27
zygaxnox: but we should be able to use the cgroup sub-directort leaf16:27
xnoxzyga:  it starts an invocation, as a dynamic .service unit. meaning one can query it with systemctl list-units snapd-execs.* for example16:28
xnoxand it can like prevent user from having two copies of the thing running in parallel, etc.16:28
zygayes, but it doesn't give me a way to run a classic snap this way, e.g. a classic installation of python, to get interactive pty16:29
vorlonxnox: well, if it's published as an exclusion, there's your answer :-)16:29
zygait needs to support all the kinds of interactions snap apps support: desktop apps, services and all the command line stuff, including classic snaps16:29
xnoxmostly useful to start "dynamic" things but monitored, i.e. executing user-written hooks, which can be arbitrary long, with journald logging, confiment, etc.16:29
xnoxit does break the scope & confiment, even basic things like "what is my stdin"16:30
zygayeah, so while we could use it for services, for services arguably systemd is already giving us all of that already16:30
zygaI think it will also be a less invasive change16:30
zygaI'm very curious about the keyring operation16:30
zygaas that seems like a way out of the too-easy-to-spoof problem16:30
xnoxzyga:  start with keyctl manpage about kernel keyring, and invocation_id stuff inside systemd16:31
zygathough it doesn't really solve the problem as you can just run the real thing (real snap app) and not close it for the same effect16:31
zygait seems like a potentially interesting replacement for the snap cookie concept though16:32
zygabut I need to read on it more now16:32
* zyga hugs xnox 16:32
zygathank you :)16:32
* cachio afk16:40
* ijohnson hugs zyga after reading backlog16:55
zygaijohnson: what specifically? :16:55
zyga:)16:55
ijohnsonthe many changes to refresh awareness, sounds like quite a rollercoaster16:55
zygaijohnson: the only question is16:55
zygaijohnson: is it still going up or are we already going down? ;)16:56
zygabut yeah, it's quite a feature16:56
ijohnsonhaha :-)16:56
* ijohnson is not really around today, still in Arizona for meetings16:57
* ogra waits for the time where the snapd snap is bigger than his kernel snaps on core images16:57
* ijohnson quietly shoves edgex snap inside snapd to get ogra to stop waiting16:58
ograhaha16:58
ograijohnson, reading that ... we'll need to talk about edgex before EOM ... (got another exhibition and we want to shw edgex finally)16:59
ograthe setup doc we have seems outdated16:59
ijohnsonsure that doc is probably out of date, but let's try to keep Tony and Don in the loop too16:59
ijohnsonogra: when is your exhibition?16:59
ogralast week of nov.17:00
ogra(i think at least ... /me checks)17:00
ograyeah, 26 to 28 https://sps.mesago.com/nuernberg/en.html17:01
ijohnsonogra: ack are you going to be in vancouver next week for the sprint?17:05
zygaogra: we will link everything into one binary so that it can stay at comfortable 20MBs forever17:11
zygamvo: heye17:11
zygamvo: you missed some nice discussion about systemd stuff with xnox17:11
zygamvo: I think I will wrap it for today17:12
zygamvo: the big takeaway is that xnox effectively confirmed that the idea from Maciek is workable17:12
zygamvo: he also raised a number of important points for us to discuss17:12
zygamvo: but I will try to propose the branch implementing this tomorrow17:12
xnoxmvo:  everything is broken and nothing works, but i made progress!17:13
mvohey zyga17:14
zygamvo: hey :)17:14
mvoxnox: ha!17:15
mvozyga: cool17:15
mvoxnox: I think we have a bug in the core20 getting17:15
mvoxnox: what kind of progress did you made?17:15
mvoxnox: the pending PR#7712 should make everything easier, I will review it tomorrow morning17:16
xnoxmvo:  see email from me. if that PR helps that's great, will try that if/when it's available to me in a track/grade/branch to me17:22
xnoxmvo:  some things i can work around with, by like passing locally downloaded snaps etc. but other things seem broken - i.e. ubuntu-image doesn't do anything for me.17:22
mvoxnox: aha, nice17:23
mvoxnox: got the mail now17:23
xnoxmvo:  and i question some design choices in the model assertion, which i guess i need to type up and send.17:23
zygaI'm wrapping up17:31
ograijohnson, no vancouver for me ...17:32
ijohnsonogra: cool maybe we could setup a hangout early next week then17:32
ograyeah, that sounds fine17:33
Chipacaok, EOD for me17:59
ChipacaπŸ‘‹17:59
=== pstolowski is now known as pstolowski|afk
mupPR snapd#7720 opened: asserts: add "snapd" type to valid types in the model assertion <Simple πŸ˜ƒ> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7720>18:48
mupPR snapcraft#2792 opened: pluginhandler: use well-formed build package/snap lists <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2792>21:04
mupPR snapcraft#2793 opened: tests: enable SNAPCRAFT_BUILD_INFO for spread <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2793>21:10
=== msalvatore_ is now known as msalvatore
=== heather is now known as hellsworth

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