[05:11] <mborzecki> morning
[05:57] <mborzecki> mvo: hey
[05:58] <mvo> hey mborzecki - good morning
[05:59] <mborzecki> mvo: when's the release?
[06:01] <mvo> mborzecki: 2.36~pre2 happend last friday but it looks like we need a 2.35.5 :/
[06:01] <mvo> mborzecki: why? anything important pending?
[06:03] <mborzecki> mvo: no, just checking if we could squeeze in https://github.com/snapcore/snapd/pull/5979
[06:03] <mup> PR #5979: install: don't start disabled services <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/5979>
[06:03] <mvo> mborzecki: mark it for 2.36 please
[06:03] <mvo> mborzecki: and alsp please mark for squash merge to merge the cherry-pick/pr easier
[06:04] <mborzecki> mvo: marked
[06:05] <mup> PR snapd#5983 opened: interfaces/home: don't allow snaps to write to $HOME/bin (2.35) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5983>
[06:06] <mvo> mborzecki: ta
[06:07] <mvo> zyga: 5974 has some comment improvement suggestions, could you do a followup with those? I will merge and pull into 2.35 so that things move here
[06:07] <mup> PR snapd#5974 closed: osutil: workaround overlayfs on ubuntu 18.10 <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5974>
[06:07] <mvo> zyga: in case you didn't already, not sure if all points where addressed
[06:25] <mvo> mborzecki: jdstrand pushed a bunch of PRs that look important but he did not attach a milestone - do you happen to know what he needs? I tagged them as 2.36
[06:25] <mvo> mborzecki: but I'm not sure if we might even pull things into 2.35 (cc zyga)
[06:27] <mborzecki> mvo: i recall the one about scrubbing env on profile change, i see it's tagged for 2.36
[07:13] <zyga> re
[07:13] <zyga> good morning
[07:13] <zyga> sorry for starting late, very very rough night
[07:13] <zyga> mvo: looking at 5974
[07:14] <zyga> ah that, I need to digest those as, as we were discussing in on IRC, we were also talking in the pull request
[07:15] <zyga> mvo: I believe all the code there is correct, we can tweak the comment
[07:15] <zyga> mvo: I will look at Jamie's pr's now
[07:15] <zyga> jdrab: https://github.com/snapcore/snapd/pull/5982 this one is very important
[07:15] <mup> PR #5982: interfaces/many: conditionally use 'unsafe' with docker-support change_profile rules <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5982>
[07:17] <mup> PR snapd#5983 closed: interfaces/home: don't allow snaps to write to $HOME/bin (2.35) <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5983>
[07:17] <zyga> the k8s pull requests are something I was not tracking so I cannot asses those
[07:18] <pstolowski> mornings
[07:18] <mvo> zyga: thanks
[07:20] <mborzecki> zyga: pstolowski: hey
[07:20] <zyga> the unsafe PR is holly smokes long :)
[07:51] <zyga> mvo: I left some comments on https://github.com/snapcore/snapd/pull/5980#pullrequestreview-164581442 - I suspect we should rename the fields/methods to match go naming scheme but otherwise this is a very welcome improvement
[07:51] <mup> PR #5980: interfaces/apparmor: conditionally add explicit deny rules for ptrace <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5980>
[07:51] <zyga> mvo: please let me know if you want to see those extra changes as additional patches in this PR directly or as a separate PR
[07:52] <mvo> zyga: ta, I have a look in a wee bit
[07:52] <zyga> British English wee bit :)
[07:53] <mvo> zyga: I don't know :) the wee as in little
[07:53] <zyga> exactly
[07:53] <zyga> that's what I meant :)
[07:53] <mvo> are there more meanings than this one?
[07:54] <zyga> not that I know of, I meant that it is specific to British English as a way to say little
[07:54] <sparkiegeek> https://en.wiktionary.org/wiki/wee#Adjective https://en.wiktionary.org/wiki/wee#Noun
[07:54] <sparkiegeek> oh, I meant to link to Etymology 2
[07:55] <zyga> lol
[07:55] <zyga> that's new :)
[07:55] <zyga> TIL wee things matter
[07:58] <zyga> pstolowski: is 5975 something we can land for 2.36?
[07:58] <zyga> it's +2 green right now
[07:59] <pstolowski> zyga: we could yes, but mvo wanted to have a look i think
[07:59]  * zyga looks at k8s pull request
[07:59] <zyga> mvo: I would vote +1 on that since it makes everyday "snap tasks" much more understandable and accurate
[07:59] <zyga> mvo: but please do see it before merging
[08:00] <pstolowski> (let's squash merge then if we do)
[08:00] <zyga> sure, please set a tag there
[08:04] <mvo> zyga: yeah, I think its good, looking now (sorry, just had to finish the classic dimension forum post before it escapes my mind again :)
[08:04] <zyga> cool, thank you for doing that - I will gladly read it soon
[08:06] <Chipaca> good morning
[08:07] <zyga> good morning sir
[08:09] <Chipaca> zyga: are we there yet?
[08:10] <zyga> no, not quite
[08:10] <Chipaca> aww
[08:23] <mvo> pstolowski: 5975 looks great, please go ahead and squash merge it so that we can backport to 2.36
[08:23] <pstolowski> mvo: great, ty!
[08:24] <mvo> zyga: anything else we might need for 2.35.5 ? if not I will go ahead with this soon
[08:29] <zyga> mvo: I don't know of anything else but let me look at the full list of PRs
[08:35] <mup> PR snapd#5975 closed: ifacestate/hooks: only create interface hook tasks if hooks exist <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5975>
[08:40] <pstolowski> mvo: merged, shall i prepare PR for 2.36?
[08:40] <mvo> pstolowski: please do
[08:40] <pstolowski> sure
[08:40] <mvo> pstolowski: thank you
[08:42] <zyga> mvo: perhaps a subset of https://github.com/snapcore/snapd/pull/5696/files
[08:42] <mup> PR #5696: interfaces/opengl: add additional accesses for cuda <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/5696>
[08:42] <zyga> where we have the extra directory but not the part that jdstrand pointed out (the mknod perm)
[08:43] <zyga> mvo: otherwise nothing else I see for 3.35.x
[08:46] <mup> PR snapd#5984 opened: ifacestate/hooks: only create interface hook tasks if hooks exist (2.36) <Created by stolowski> <https://github.com/snapcore/snapd/pull/5984>
[08:51] <mvo> zyga: thanks for double checking. I looked at 5980, it looks good, I agree with your comments about naming conventions though
[08:51] <zyga> I can push a patch to change it there and in the other PRs that are built on it
[08:52] <pstolowski> mvo, zyga ^ pr for 2.36 is up
[08:52] <mborzecki> pstolowski: did a pass on #5962
[08:52] <mup> PR #5962: ifacestate/hotplug: hotplug handlers <Complex> <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5962>
[08:52] <mvo> pstolowski: cool, thanks
[08:54] <mborzecki> heh github, if you search with query https://github.com/snapcore/snapd/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+%F0%9F%94%8C (using the hotplug emoji) it finds no PRs
[08:55] <pstolowski> mborzecki: thanks!
[09:07] <pstolowski> mborzecki: +1 for #5966, with one remaks (perhaps degville can help again)
[09:07] <mup> PR #5966: snap: overhaul validation error messages <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5966>
[09:10] <niemeyer> Yeah, the emojis are funny, but we should probably drop them
[09:10] <niemeyer> Morning all
[09:11] <mvo> good morning niemeyer
[09:12] <niemeyer> mvo: Yo
[09:12] <Chipaca> mborzecki: does searching by the contents of a tag find things? (doesn't work with 'complex' either)
[09:13] <mborzecki> Chipaca: probably not, seems like freetext search ignores labels
[09:20] <mvo> Chipaca: a while ago you looked into uc16 to ensure things cleanly unmount on stop/reboot, do you think you could you do the same for uc18 again?
[09:21] <Chipaca> mvo: I think I probably could :-) do you know it doesn't?
[09:21] <mvo> ppisati: did you had any luck getting to the bottom of the 4.15 pi3 b+ ethernet connection issues?
[09:21] <mvo> Chipaca: I suspect it might be :/
[09:22] <Chipaca> mvo: ok. Is there a working intel core18 i could look at?
[09:22] <mvo> Chipaca: http://people.canonical.com/~mvo/core18/
[09:22] <mvo> Chipaca: so http://people.canonical.com/~mvo/core18/core18-amd64-18-beta20180823.img.xz
[09:22] <Chipaca> thanks
[09:22] <mvo> Chipaca: should work, please do let me know if you notice anything
[09:23] <mvo> Chipaca: thank *you*
[09:24] <pstolowski> mvo: i think #5969 needs master merged, the base PR already landed
[09:24] <mup> PR #5969:  apparmor: add unit test for probeAppArmorParser and simplify code  <Created by mvo5> <https://github.com/snapcore/snapd/pull/5969>
[09:25] <mvo> pstolowski: thanks, done
[09:27] <pstolowski> thx
[09:28] <ppisati> mvo: the fix is already queued in bionic
[09:29] <mvo> ppisati: \o/
[09:29] <mvo> ppisati: great to hear, do you have a rough eta for the snap? I guess its too much work to just do an edge build of the pi-kernel (?)
[09:32] <ppisati> mvo: as soon as the new SRU kernel is released - IIRC they cut a new kernel tomorrow, then it's 2 weeks after that
[09:32] <ppisati> mvo: but there was a respin of kernels last week, so the window might have slide a bit
[09:34] <ppisati> *slid
[09:35] <mvo> ppisati: ok. I wish we had git snapshots in the edge channel :) but I guess that is a wishlist item for another day. might actually be nice for you guys as well to get people testing/validating fixes
[09:35] <mvo> ppisati: thanks for this update!
[09:42] <mborzecki> Chipaca: i'm looking at snapshot file names, the code does not reverse the file name anywhere, so we sould be safe there wrt. parallel instances and extra _
[09:43] <Chipaca> mborzecki: yep, the filename is for the sysadmin, snapshots doesn't infer info from it
[09:43] <mborzecki> Chipaca: mhm, cool
[09:43] <Chipaca> mborzecki: only thing where it might be a problem is creating duplicate filenames, which we might not check for
[09:43] <Chipaca> mborzecki: but we use InstanceName so should be fine, afaik
[09:43] <mborzecki> Chipaca: yes, instance names are unique
[09:43] <Chipaca> i mean afaik we use instance name :)
[09:44] <Chipaca> mvo: how long does the 'resize partition' step take, usually? boot's been stuck there for a while now
[09:46] <mvo> Chipaca: probably entropy :(
[09:46] <mvo> Chipaca: just hammer at some keys
[09:46] <Chipaca> heh, that was it
[09:47]  * mvo weeps a bit in the corner about this problem
[09:47] <mborzecki> heh, wonder what one will do when there's no keyboard attached
[09:48] <mborzecki> wiggle some gpios
[09:48]  * Chipaca suddenly wishes for "base: core | core18
[09:51] <Chipaca> huh
[09:51] <Chipaca> mvo: a 'snap install' got aborted by a refresh of core18; is that expected?
[09:51] <zyga> aborted?
[09:51] <zyga> can we even do that?
[09:52] <Chipaca> might've been just coincidence
[09:52] <Chipaca> 'snap tasks' say 'server misbehaving'
[09:57] <zyga> mvo: actually
[09:57] <zyga> mvo: perhaps https://github.com/snapcore/snapd/pull/5982#pullrequestreview-164628872 is a candidate for .5
[09:57] <zyga> mvo: but it is stacked on top of a pile of other things
[09:57] <zyga> so unsure
[09:57] <mup> PR #5982: interfaces/many: conditionally use 'unsafe' with docker-support change_profile rules <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5982>
[09:58] <zyga> you marked that PR as targeting 2.36 so perhaps you know better
[10:09] <Chipaca> mvo: bad news: we're hitting a variant of https://github.com/systemd/systemd/issues/8155
[10:10] <mvo> zyga: I can wait for jamie to clarify
[10:11] <mvo> Chipaca: uhhh
[10:11] <Chipaca> mvo: maybe :)
[10:11]  * Chipaca is still digging
[10:11] <Chipaca> but, yeah, we just see the nasty [  364.293811] systemd-shutdown[1]: Failed to wait for process: Protocol error
[10:11] <Chipaca> which seems to mean that systemd < 238
[10:12] <mvo> Chipaca: hrm, hrm, or would need to sru
[10:12] <Chipaca> yeah, systemd --version says 237
[10:12] <Chipaca> we could also backport https://github.com/systemd/systemd/pull/8429/files
[10:12] <mup> PR systemd/systemd#8429: sd-shutdown improvements <ci-fails/needs-rework 🔥> <merged-but-needs-fixing> <pid1> <Created by medhefgo> <Merged by keszybz> <https://github.com/systemd/systemd/pull/8429>
[10:13] <zyga> uh fun
[10:13] <zyga> (not)
[10:13] <Chipaca> mvo: but all that _really_ does is turn up the logging
[10:13] <Chipaca> bah, maybe :)
[10:13] <Chipaca> for our case it might be the only difference
[10:13] <Chipaca> i wonder if i can't turn up the logging without that
[10:13] <mvo> Chipaca: ok
[10:22] <Chipaca> mvo: so. we might not need that patch
[10:22] <Chipaca> mvo: it's just that our systemd-shutdown helper unit isn't getting triggered
[10:22] <Chipaca> digging continues
[10:23] <Chipaca> that is: if I set it up by hand, I get
[10:23] <mvo> Chipaca: oh, nice
[10:23] <Chipaca> Successfully changed into root pivot.
[10:23] <Chipaca> Returning to initrd...
[10:23] <Chipaca> snapd system-shutdown helper: started.
[10:23] <Chipaca> snapd system-shutdown helper: no reboot parameter
[10:23] <Chipaca> snapd system-shutdown helper: * unable to disassociate loop device /dev/loop0s: No such device or address
[10:23] <Chipaca> snapd system-shutdown helper: - was able to unmount writable cleanly
[10:23] <Chipaca> snapd system-shutdown helper: - halting.
[10:23] <mvo> Chipaca: so maybe just a missing symlink to activate it?
[10:23] <Chipaca> pr'aps
[10:23] <Chipaca> rebooting to see :-)
[10:23] <zyga> Chipaca: really /dev/loop0s?
[10:23] <mvo> Chipaca: I can look for this is that helps you :)
[10:23] <zyga> what even is that
[10:24] <Chipaca> $ systemctl is-enabled snapd.system-shutdown.service
[10:24] <Chipaca> enabled
[10:25] <Chipaca> mvo: so it's not that :-|
[10:25] <Chipaca> zyga: ¯\_(ツ)_/¯
[10:26] <Chipaca> zyga: /dev/loop0; the s is probably a typo
[10:26] <Chipaca> zyga: 			kmsg("* unable to disassociate loop device %ss: %s",
[10:26] <zyga> ah
[10:26] <Chipaca> :)
[10:26] <zyga> good
[10:26] <zyga> at least
[10:26] <zyga> loop0 is probably the boot snap
[10:27] <Chipaca> it's probably fine;  disassociation is automatic after dunno-what-utils-linux-version
[10:28] <Chipaca> mvo: so,  the unit is enabled; it's not getting activated afaict
[10:28] <Chipaca> probably changes to systemd-shutdown
[10:29] <mvo> Chipaca: :/ hrm, hrm
[10:30] <Chipaca> ah
[10:30] <Chipaca> i think i might know why
[10:32] <Chipaca> mvo: the snapd snap does not ship sh
[10:33] <zyga> huh? why would we need to ship sh?
[10:34] <Chipaca> well, we don't, but we then create snapd.system-shutdown.service as if we did
[10:34] <zyga> is the service using shell?
[10:35] <Chipaca> sudo sed -i -e 's|/snap/snapd/659/bin/sh|/snap/core18/304/bin/dash|' /etc/systemd/system/snapd.system-shutdown.service && sudo systemctl daemon-reload -> works
[10:35] <Chipaca> zyga: ExecStart=/snap/core18/304/bin/dash -euc 'mount /run -o remount,exec; mkdir -p /run/initramfs; cp /usr/lib/snapd/system-shutdown /run/initramfs/shutdown'
[10:35] <zyga> ohohh
[10:35] <zyga> I see
[10:36] <mvo> Chipaca: oh woah - nice catch!
[10:36] <Chipaca> I don't remember why it does that instead of having multiple ExecStart= lines
[10:36] <Chipaca> let me try that instea
[10:36] <Chipaca> probably more portable
[10:36]  * Chipaca tries
[10:37] <Chipaca> of course if I had 'vi' this would be slightly easier :-D
[10:39] <mvo> Chipaca: I thought we added this
[10:39] <mvo> Chipaca: maybe you need a newer core18?
[10:39] <Chipaca> mvo: I'll let it refresh
[10:40] <mvo> ok
[10:40] <Chipaca> mvo: which 'this' is this, btw?
[10:42] <mvo> Chipaca: I thought we added "vi" to core18
[10:42] <mvo> (vim.tiny to be exact)
[10:42] <Chipaca> mvo: ah, possibly, it seems the core image was ~200 revisions behind
[10:44] <zyga> brb, dog
[10:45] <Chipaca> ok
[10:45] <Chipaca> so
[10:45] <Chipaca> easy fix
[10:45] <mup> PR snapd#5985 opened: overlord/many: cleanup use of snapName vs. instanceName <Parallel installs ⛓> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5985>
[10:46] <mvo> Chipaca: I like the ring of "easy fix" \o/
[10:47] <Chipaca> mvo: what creates snapd.system-shutdown.service?
[10:48] <Chipaca> mvo: found it
[10:51] <Chipaca> hmm
[10:51] <Chipaca> mvo: what changes /bin/sh to /snap/snapd/<revno>/bin/sh ?
[10:55] <Chipaca> mvo: found it
[10:55] <sil2100> mvo: I have uploaded the probert with the fix for db that mwhudson prepared to our PPA, once it's built I'll be triggering a new core18
[10:56] <sil2100> Once that's in would be nice to confirm that the probert crash is gone
[10:56] <sil2100> zyga: ^
[11:00] <mvo> sil2100: nice
[11:00] <mvo> sil2100: I will test with my pi-64bit
[11:01] <zyga> As will once back
[11:02] <mvo> sil2100: nice fix
[11:03] <mvo> sil2100: great that this is under control
[11:14] <mvo> Chipaca: fwiw, this fix sounds a lot like we want it in 2.35.5 just to be one the safe side (if its someting that needs to go into snapd)
[11:15] <Chipaca> k
[11:15] <mvo> Chipaca: ta
[11:15] <mvo> Chipaca: but don't worry about this, I can do the backporting etc
[11:16] <Chipaca> mvo: there is no worry; there is only do
[11:16] <mvo> :)
[11:16] <mvo> DO!
[11:16]  * mvo hugs Chipaca 
[11:22] <zyga> sil2100: is that the image from Friday good for testing?
[11:23] <zyga> mvo: release day is like xmas
[11:23] <zyga> everyone has a present
[11:23] <sil2100> No, not yet
[11:23] <sil2100> I mean, not anymore ;)
[11:23] <sil2100> I'll have a new one soonish
[11:23] <zyga> ok
[11:23] <sil2100> The packages  need to publish though
[11:24] <zyga> I'll grab lunch quickly then
[11:26] <mup> PR snapd#5986 opened: data/systemd, wrappers: tweak system-shutdown helper for core18 <Simple 😃> <Created by chipaca> <https://github.com/snapcore/snapd/pull/5986>
[11:26] <Chipaca> mvo, zyga: ^
[11:26] <Chipaca> ooh, lunch, a capital idea
[11:26] <pstolowski> mborzecki: +1 on  #5985, would be good to land it fast
[11:27] <mup> PR #5985: overlord/many: cleanup use of snapName vs. instanceName <Parallel installs ⛓> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5985>
[11:28] <mvo> Chipaca: thank you
[11:33] <zyga> Chipaca: reviewed
[11:39] <sil2100> mvo: ummm, could you re-build core18 snap? Since currently I guess the main snap recipe is owned by you for now
[11:39] <sil2100> probert is good
[11:49] <mborzecki> off to pick up the kids
[11:58] <jdstrand> mvo: hi!
[12:00] <jdstrand> mvo: I didn't tag those as 2.36 because I wasn't sure how suitable they were for it at this point in time and was going to let you decide (they are bigger than whatI (and probably you) were expecting last week
[12:00] <jdstrand> needless to say, they took more than 'a few hours'
[12:01] <jdstrand> mvo: I mean, I'm happy if they go into 2.36, but having them just in trunk is ok too
[12:01] <jdstrand> mvo: but I wanted to talk to you about this: audit: type=1400 audit(1539604887.557:452): apparmor="DENIED" operation="exec" profile="snap.hello-world.env" name="/sbin/apparmor_parser" pid=30864 comm="snap-exec" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
[12:02] <jdstrand> mvo: it seems every snap run invocation is causing this. let me know when you have a moment
[12:03] <zyga> woah?
[12:03] <zyga> so snap-exec runs apparmor_parser
[12:03] <zyga> probably in the quest to compute system key
[12:03] <zyga> or something similar?
[12:03] <jdstrand> that is what I was thinking
[12:03] <zyga> what is worse
[12:03] <zyga> if apaprmor is updated
[12:03] <zyga> and we have a new apparmor parser
[12:03] <zyga> the system key will not match
[12:04] <zyga> but snapd doesn't care about the upgrade in the system
[12:04] <zyga> so it will always be wrong
[12:04] <jdstrand> so, release/apparmor.go init(), there is:
[12:04] <jdstrand> appArmorLevel, appArmorSummary = probeAppArmor()
[12:04] <zyga> until you reboot and snapd considers this
[12:04] <jdstrand> appArmorParserFeatures = probeAppArmorParser()
[12:04] <jdstrand> what is weird though, is if this is the issue, then why don't I see denials from probeAppArmor?
[12:05] <jdstrand> I only see denials for probeAppArmorParser
[12:05] <zyga> I think we allowed the former
[12:05] <jdstrand> I looked in the template. let me look again
[12:05] <zyga> oh, in that case I don't know
[12:05] <jdstrand> also, I was really surprised that snap run is doing all these checks
[12:05] <jdstrand> it isn't like it can do anything with the result
[12:06] <zyga> I think we d
[12:06] <zyga> we spin and wait
[12:06] <zyga> that's the purpose of system key there
[12:06] <jdstrand> and we are adding a bunch of stat()s and an exec() to the snap run
[12:06] <jdstrand> hmm
[12:06] <jdstrand> I definitely didn't mean for apparmor_parser to be called every time that an app was run
[12:06] <zyga> right
[12:07] <jdstrand> quite the opposite. I didn't even want it run every time a profile was compile
[12:07] <zyga> I think this falls under the idea I had a while ago with "facts" in /var/lib/snapd/facts - that would be written by snapd and interrogated by other parts of the stsack
[12:07] <jdstrand> I wanted it precisely once when snapd started :)
[12:07] <jdstrand> and I thought that was what happened with system-key
[12:07] <zyga> mmm, not quite
[12:07] <zyga> you need to be able to compute the system key
[12:07] <jdstrand> well, clearly
[12:07] <zyga> in snap-run
[12:08] <zyga> and quickly too as you now learned
[12:08] <jdstrand> we need to short circuit this or move it
[12:08] <jdstrand> I mean we could add a rule, but blech, I don't want this-- it is only useful for profile generation
[12:08] <zyga> I agree
[12:08] <zyga> hmmm hmm
[12:08] <jdstrand> snap run can literally do nothing with the information
[12:12]  * pstolowski lunches
[12:12] <zyga> jdstrand: if you need me for this just ask, otherwise I'll be going through per user mount namespaces
[12:14] <jdstrand> yeah, I don't see /sys/kernel/security/apparmor/features in the template
[12:14] <jdstrand> zyga: thanks, I'll discuss with mvo and we can decide from there
[12:15] <jdstrand> it is definitely denied: $ ls /sys/kernel/security/apparmor/features/
[12:15] <jdstrand> ls: cannot open directory '/sys/kernel/security/apparmor/features/': Permission denied
[12:17] <jdstrand> so, probeAppArmor() is not getting called, but probeAppArmorParser() is...
[12:18] <jdstrand> which makes no sense cause they are both only called via init()...
[12:19]  * jdstrand is confused
[12:27] <zyga> perhaps probe apparmor is really lazy?
[12:29] <jdstrand> huh
[12:29] <jdstrand> ./interfaces/system_key.go:sk.AppArmorParserFeatures = release.AppArmorParserFeatures()
[12:29] <jdstrand> ./interfaces/apparmor/backend.go:parserFeatures        = release.AppArmorParserFeatures
[12:30] <jdstrand> so in system_key, we assign '()' but in backend.go we do not
[12:31] <jdstrand> that is the same with AppAmorFeatures though...
[12:32] <zyga> !
[12:35] <mborzecki> re
[12:36] <jdstrand> maybeWaitForSecurityProfileRegeneration() does call interfaces.SystemKeyMismatch()
[12:40] <jdstrand> I'm really puzzled that I'm not seeing denials from release.AppArmorFeatures() but I am for release.AppArmorParserFeatures()
[12:41] <mvo> sil2100: sure
[12:41] <mvo> jdstrand: hi, reading backlog (looks like there is a lot of it :)
[12:41] <jdstrand> mvo: yes, halp :)
[12:42] <zyga> (insert 5th element quote0
[12:43] <jdstrand> I wonder what ioutil.ReadDir() is doing
[12:43] <jdstrand> maybe it doesn't trigger the apparmor denial
[12:44] <jdstrand> but then that would be a bug in system-key detection
[12:46] <jdstrand> hmm, it is just an os.Open
[12:51] <Chipaca> jdstrand: ls /sys/kernel/security/apparmor/features/ triggers the denial, but does stat on its own?
[12:52] <jdstrand> Chipaca: it would not, no
[12:53] <zyga> stat is not mediated anywhere AFAIK
[12:53] <Chipaca> jdstrand: maybe whatever's triggering the denial is not one of the required features that we stat in probeAppArmor
[12:53] <jdstrand> yes, that is what it is Chipaca
[12:53] <Chipaca> ah
[12:53] <jdstrand> probeAppArmor only does an isDirectory() which is just a stat
[12:54] <Chipaca> yup
[12:54] <Chipaca> and a rather dumb stat at that :)
[12:54] <zyga> aaah
[12:54] <jdstrand> ok, so mystery solved on the why probeAppArmor() doesn't trigger denials
[12:54] <zyga> man, that's magic
[12:54] <jdstrand> mvo: ^
[12:54] <mvo> jdstrand: I just finished reading backlog - indeed, we compute the system-key in snap run, sorry that I did not realize during the review about the implication of the apparmor parser test
[12:54] <jdstrand> so, the question is how to fix probeAppArmorParser
[12:54] <mup> PR snapd#5987 opened: cmd: refactor IPC and lifecycle of the helper process <Created by zyga> <https://github.com/snapcore/snapd/pull/5987>
[12:55] <mvo> jdstrand: let me quickly look at this (its 5min until our standup)
[12:55] <zyga> standup time but I'll be 3 min late
[12:55] <zyga> brb
[12:56] <jdstrand> mvo: so, on the one hand, it does make sense that we might wait for profile regeneration for the unsafe, but on the other, I'd *way* much prefer we *not* exec apparmor_parser in every snap run
[12:56] <mvo> jdstrand: from the top of my head: probe once and then save the result in e.g. /run/snapd
[12:56] <jdstrand> mvo: that's what I was trying to do :)
[12:56] <jdstrand> mvo: you mean, just touch a file?
[12:56] <mvo> jdstrand: yeah
[12:56] <jdstrand> mvo: ok, let me work through that
[12:57] <mvo> jdstrand: thanks, the other option would be to simply not make it part of system-key and hope that something else triggers a re-run
[12:57] <jdstrand> mvo: which do you prefer?
[12:57] <mvo> jdstrand: let me quickly look at what goes into system-key already
[12:58] <mvo> jdstrand: it partly depenends on your preferences as well, if we remove it from the system-key worst case is that the profile is only re-generated with the next snapd refresh
[12:58] <jdstrand> it would be fast to add a touch at the end of probeAppArmorParser and then stat for it at the top
[12:58] <jdstrand> mvo: I think that is least correct
[12:59] <mvo> jdstrand: yeah, and cheapest :)
[12:59] <jdstrand> mvo: no, I meant removing and hoping is least correct
[13:00] <jdstrand> mvo: but is is also not correct to touch the file. cause, well, in theory the parser could've been updated in the mean time (that was always true with the intent of the original PR
[13:00] <jdstrand> )
[13:00] <mvo> jdstrand: we could use the mtime of apparmor_parser as input
[13:00] <mvo> of system-key
[13:01] <jdstrand> mvo: so, mtime and touch?
[13:02] <mvo> jdstrand: mtime of /usr/bin/apparmor_parser and if that changes the system-key changes and we re-generation apparmor. and when doing that we check apparmor features
[13:02]  * jdstrand doesn't see how mtime is enough
[13:03] <jdstrand> that would require redoing system key generation a bit, no?
[13:03] <jdstrand> well wait
[13:04] <jdstrand> ok, I add mtime to the systemKey struct. then I always just check for that
[13:04] <jdstrand> so, that is a stat, and we only call probeAppArmorPaarser if they are different
[13:05] <jdstrand> ok, let me look at that
[13:11] <mvo> jdstrand: thank you! in the standup right now so I may be a bit slow replying
[13:28] <Chipaca> jdstrand: dunno if it helps, but i've got this in my bash history: grep -rl --include \*.go --exclude \*_test.go '^func init()' | xargs perl -pi -we 's/(^func init\(.*)/\1\nprintln("$ARGV")/'
[13:29] <Chipaca> jdstrand: adds a print to any and all init, so you can easily spot unexpected inits
[13:33] <zyga> jdstrand: offtopic, I think you should enqueue https://github.com/snapcore/snapd/pull/5885
[13:33] <mup> PR #5885: Adding DPDK interface for DPDK Snap <Created by wililupy> <https://github.com/snapcore/snapd/pull/5885>
[14:01]  * Chipaca hugs mborzecki 
[14:02]  * mvo hugs mborzecki as well well
[14:02] <mborzecki> why the hugs?
[14:02] <mvo> jdstrand: standup over, anything I can help with?
[14:02] <Chipaca> niemeyer: dunno if you saw but at least mborzecki isn't here in 1h
[14:02] <Chipaca> mborzecki: no, that you said the above just as we wrapped (and I feel guilty because I said "yes", for myself, but know how that can be taken as a for all so I should've waited)
[14:03] <mvo> mborzecki: because Chipaca started it :) *grouphug*
[14:03] <Chipaca> :)
[14:03] <mvo> Chipaca: I think its fine, we just skip the bits from mborzecki  and talk about them tomorrow, no?
[14:03] <niemeyer> Chipaca: Ah, I didn't realize.. well, we can get together either way and just finish that list.. tomorrow we can review the whole thing again
[14:04]  * Son_Goku hugs mborzecki 
[14:04] <mborzecki> works for me
[14:04] <Son_Goku> I'm just happy someone besides me actually bothers to investigate SELinux stuff, so you deserve hugs from me anyway :D
[14:04] <jdstrand> mvo: not yet
[14:04] <mvo> ok
[14:05] <Son_Goku> mborzecki, when 2.36 becomes available, I'm going to push out for epel7 at the same time as fedora
[14:05] <zyga> mborzecki: hey, I pushed a few tweaks to snap-confine, would you be willing to look
[14:05] <zyga> it's nothing major really, and not that long
[14:05] <zyga> mostly a switch to pipe
[14:15] <jdstrand> Chipaca: that's interesting. thank you
[14:16] <mborzecki> Son_Goku: nice, thank you!
[14:27] <mup> PR snapd#5988 opened: cmd: rename ns_group to mount_ns <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/5988>
[14:32] <zyga> mvo: if you can, please land that, that's just a rename
[14:32] <zyga> ^
[14:36] <mvo> zyga: sure, I have a look
[14:41] <zyga> thank you!
[15:02] <niemeyer> zyga: You coming?
[15:02] <zyga> ah, sure
[15:02] <zyga> niemeyer: same URL?
[15:03] <degville> zyga: yep
[15:21] <mup> PR snapcraft#2353 opened: tests: remove dependency on snapcraft for integration tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2353>
[15:38] <ackk> hi, can classic snaps run deamons as specific system users?
[15:49] <smoser> zyga: is there expected to be a new snapd upload before release  of 18.10 ?
[16:25] <zyga> smoser: I defer to our release manager, mvo
[16:25] <zyga> I don't know
[16:26] <zyga> ackk: not at present
[16:26] <zyga> unless said daemons do that themselves
[17:20] <ackk> zyga, meaning, you can "su" as a different user from classic, right? IOW a daemon could run as "nobody" in that case?
[17:36] <kyr0> Hi, I have a snap package that when I launch it from the terminal, nothing happens. Where should I start to troubleshoot?
[17:45] <zyga> re
[17:45] <zyga> ackk: correct
[17:45] <zyga> kyr0: hello
[17:45] <zyga> kyr0: it depends on the software but you may have some good idea what is happening in general by using:
[17:46] <zyga> kyr0: SNAPD_DEBUG=1 snap run ...
[17:46] <zyga> (or just the program name)
[17:49] <kyr0> zyga: Thank you, ill start my investigation.
[17:50] <zyga> kyr0: you can also run "snap run --shell" to enter a shell with the same confinement
[17:50] <zyga> kyr0: but note, not the same environment
[17:50] <zyga> some of the environment is set by wrapper scripts in $SNAP
[17:50] <zyga> cd $SNAP to look around
[17:50] <zyga> you can run those scripts directly to execute the same command
[17:53] <zyga> hmm
[17:53] <zyga> Chipaca: still hear?
[17:53] <zyga> here*
[17:53] <kyr0> zyga: Thanks, i'll start looking into it
[18:44] <Chipaca> zyga: yes
[18:44] <zyga> oh god why :)
[18:44] <zyga> ok
[18:44] <zyga> I was thinking about taking the accounts service test manual for a moment
[18:44] <Chipaca> zyga: finished dinner, came to eod
[18:44] <zyga> it's failing all the time
[18:44] <zyga> wanted to discuss ideas
[18:44] <zyga> but can wait
[18:44] <zyga> not urgent :)
[18:44] <Chipaca> zyga: i've left it looping here to see if i can catch the failure
[18:45] <zyga> I caught it once
[18:45] <Chipaca> on iteration 20 with no failures
[18:45] <zyga> forgot about it
[18:45] <zyga> closed terminal
[18:45] <zyga> yes ;)
[18:45] <zyga> I would suggest adding ps aux to debug
[18:45] <zyga> I bet there's something very odd running then
[18:45] <zyga> (not accounts service)
[18:45] <Chipaca> yeap
[18:46] <Chipaca> zyga: instead of 'gdbus monitor --session --dest yadda', i'd do 'dbus-monitor --session' which is a lot more chatty
[18:46] <Chipaca> but, that assumes I can reproduce the issue :-D
[18:46] <zyga> Chipaca: is your unmount fix ready?
[18:47] <Chipaca> zyga: well, its spread is red, if that's what you're asking
[18:47] <Chipaca> or was when i looked last
[18:47] <Chipaca> zyga: https://api.travis-ci.org/v3/job/441628807/log.txt
[18:47] <Chipaca> zyga: the last run, degraded and snap-repair failed, which … not sure what those are about
[18:47] <zyga> I see
[18:48] <Chipaca> suspect something is actually broken
[18:48] <zyga> ah
[18:48] <zyga> I was just chatting with mvo about a possible release tonight
[18:48] <Chipaca> that'd be nice but integration tests aren't cooperating
[18:48] <Chipaca> and i don't know enough about those two tests to know if they're real or not
[18:49] <Chipaca> they're failing on core 18
[18:49] <Chipaca> are you seeing them fail there as well?
[18:49] <zyga> I see the error log now
[18:52] <zyga> hmmm
[18:56] <zyga> Chipaca: is ExecStart= ... ordered?
[18:57] <zyga> seems so according to manual pages
[19:12] <mup> PR snapd#5989 opened: interfaces/system-key: add parser mtime and only discover features on write <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5989>
[19:13] <Chipaca> zyga: yes, it's ordered
[19:13] <Chipaca> zyga: and yes it stops as soon as one fails, unless it starts with -
[19:36] <kyrofa> How is the possibility for a 2.36 release looking this week?
[19:44] <Chipaca> kyrofa: 0.47
[19:45] <Chipaca> kyrofa: but i'm probably overly pessimistic, so maybe it's .87
[19:57] <kyrofa> Chipaca, I'll take your earlier assessment :P
[19:58] <Chipaca> kyrofa: I hope I'm wrong, because I'm itching to update the brew formula so it no longer neads --HEAD
[20:24] <mup> PR snapcraft#2349 closed: extensions: use extension docstring <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2349>
[20:50] <popey> Chipaca: fyi, that person you conversed with was a spammer, i removed them
[20:50] <popey> (on the forum)
[20:50] <Chipaca> popey: they were? their question seemed relevant
[20:50] <Chipaca> booo
[20:50] <popey> it was a copy/pasta from a reddit thread a year ago
[20:50] <Chipaca> oh
[20:50] <popey> they do that to get credit on the forum, then slip a url edit in a few days later
[20:50] <Chipaca> right
[20:51] <popey> i didnt spot it until the edit
[20:53] <Chipaca> how isn't there an emoji for spam
[20:54] <popey> trademarks i guess
[20:54] <Chipaca> 🥫 came so close
[20:55] <Chipaca> anyhoo, it's a relief as the "why do i need to log in" thing should be well dead
[21:00] <popey> Yeah, i recently requested an edit to the appimage wiki because it claimed we still needed to login
[21:00] <popey> xkcd 386
[21:15] <mup> PR snapcraft#2354 opened: Preflight missing multipass <Created by evandandrea> <https://github.com/snapcore/snapcraft/pull/2354>
[21:54] <mup> PR snapcraft#2350 closed: extensions: parse all declared extensions before applying <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2350>
[22:24] <mup> PR snapcraft#2355 opened: extensions: cleanup and generic tests <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2355>
[22:27] <mup> PR snapcraft#2246 closed: packaging: cleanup extension usage in setup.py <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/2246>