=== chihchun is now known as chihchun_afk [02:34] Saviq, hey, please try the image fedora-rawhide-64, tomorrow I'll ping you === chihchun_afk is now known as chihchun [06:12] morning [06:19] Hi [06:20] Some late night pull requests [06:20] With green 2.36 [06:20] :-) [06:37] heh :) went to a meetup yday, then i stayed until midnight making that damn selinux work, audit actually showed some interesting behavior by journald poking some attributes in /proc all the time [06:39] Cool, looking forward to that [06:39] My son is 1/3rd my age today [06:40] Feeling old or young? :-) === chihchun is now known as chihchun_afk [07:23] re [07:23] mborzecki: hey [07:23] so today we will try to stabilize 2.36 and merge the bits back into master [07:23] mborzecki: this is part of the issue https://github.com/snapcore/snapd/pull/6233 [07:23] PR #6233: overlord: don't write system key if security setup fails [07:24] mborzecki: this is a more complete view but as you will see there it cannot land just yet https://github.com/snapcore/snapd/pull/6235 [07:24] PR #6235: overlord,apparmor: new syskey behaviour + non-ignored snap-confine profile errors [07:24] each commit has some description that explains what was going on [07:24] Chipaca: good morning sir! [07:25] I need to run an errand in the morning (wife doctor checkup) but I will be back as soon as I can [07:34] zyga: goodmorning [07:35] * Chipaca not legally awake yet [07:40] PR snapd#6236 opened: Staticcheck fixes [07:58] Hey mvo [07:58] I’m afk on the way to a doctor with my wife (all is good, no worries) [07:59] I sent some PRs last night [07:59] Please have a look [07:59] zyga: cool [07:59] zyga: thanks, I check the PRs === pstolowski|afk is now known as pstolowski [08:00] If you have time I would love more eyes on the trio of pastebins from yesterday [08:00] To be confident we understand how things happen [08:01] After I am back I will post leap fixes [08:01] Together this will fix 2.36 as we understand it so far [08:06] zyga: great [08:11] zyga: I asked a question in one of them [08:14] morning [08:15] hey pstolowski [08:18] pedronis: replied now [08:18] Actually [08:18] Hmmm [08:18] More problematic [08:19] Oh boy :-) [08:19] Something to think about [08:19] zyga: I thought we already added the waiting to snap-confine, is that false? [08:21] No system key, no snap run [08:21] pedronis: thanks for adding the todo to 6195 [08:21] I’m afk partially sorry for laggy replies [08:21] zyga: ? [08:21] I thought we did something saner [08:22] I’m not at home, doctor visit with wife [08:22] zyga: ok, let' chat later [08:22] mvo: do you know what snap-confine does if there's no system-key? I thought it would wait a while [08:23] pedronis: it will wait a while, do you see something different? [08:23] pedronis: it should try to talk to snapd in this case [08:23] This is really about a restart case [08:23] zyga: is saying something else [08:23] So we error because we are restarting [08:23] It will be fixed by next startup [08:23] ? [08:23] error where [08:23] something sounds wrong [08:24] is snap-confine assuming that snapd runs all the time [08:24] that's a bit optimistic [08:24] pedronis: well, we had a long discussion abut this when we introduced the system key [08:24] mvo: I mean if snap-confine needs to wait and can't talk to snapd it should wait a bit more and try again, no? [08:25] pedronis: I can look in a bit for the details, I think we wrote it down. at least gustavo and me, don't remember if you were part of it [08:25] I can hop on a voice call if you want to discuss this in detail [08:25] until some timeout [08:25] pedronis: yes, thats correct [08:25] is it simply dying if snapd is not there [08:25] ? [08:25] pedronis: is this not what you see? [08:25] That is what currently happens [08:25] pedronis: no, it should not [08:25] zyga: oh? [08:25] It waits [08:25] And then might die if something required is missing [08:25] AFAIK [08:26] I am just trying this [08:26] it definitely waits [08:26] then is as designed, no? [08:26] I mean, I don't expect this to work 100% [08:26] Yes [08:26] I think this is as designed [08:26] it should not fail on boot 100% [08:26] and when I start snapd again it will continue [08:26] either [08:26] we might have a problem in that [08:27] the timeout might be shorter than it takes to regen all security if lots of snaps ? [08:28] Yes [08:28] yes, that could be a problem :( [08:28] is not a problem for today tough [08:28] but zyga scared a bit, like snap-confine would not to do what I remember was designed to do [08:28] it waits 60s right now [08:29] pedronis, zyga let me try this [08:29] what were we calling the feature where we'd delay a snap refresh until the app was closed? [08:29] 6195 still needs a second review [08:30] I think it is not perfect but as designed === chihchun_afk is now known as chihchun [08:30] as I said I don't expect perfect (kind of impossible given the constraints), we might have to improve over time in some corners [08:31] but for a second it sounded like it was broken [08:31] I was scared :-) [08:31] hm, it seems to error when it hits the timeout - iirc we wanted it to continue (best effort) - yes? [08:32] Chipaca: we call it "Prevent refreshes while running" [08:32] at least that's the name of the day [08:32] pedronis: is there a forum topic about it? [08:33] asking because https://forum.snapcraft.io/t/concerns-about-consistency-and-data-corruption-during-snap-refresh/8741 [08:33] yea, I saw that one [08:33] if there isn't, i'll just reply vaguely [08:33] :-) [08:36] Chipaca: I don't see one, is mentioned in the last sprint topics but not as a discussed one [08:36] anyway is planned for the cycle [08:37] pedronis: https://forum.snapcraft.io/t/concerns-about-consistency-and-data-corruption-during-snap-refresh/8741/2?u=chipaca [08:37] ¯\_(ツ)_/¯ [08:38] mvo: #6195 gtg fwiw [08:38] PR #6195: snapstate: update fontconfig caches on install [08:39] Chipaca: thx [08:39] * Chipaca wanders off in search of coffee [08:41] I could use some too [08:41] Waiting for blood tests now [08:42] * mvo gets some lovely tea [08:43] I’m happy nobody mentioned nutrient breakfast yet [08:43] mvo: I saw somebody using "material tea timer" and thought you might like it (if you didn't have it already) [08:43] mvo: https://play.google.com/store/apps/details?id=org.ligi.materialteatimer [08:44] Chipaca: nice! [08:44] Chipaca: I don't have it, I use the boring clock app [08:44] Chipaca: but this even has nice pics (teap0rn) [08:45] mvo: and it's FOSS [08:45] \o/ === chihchun is now known as chihchun_afk [09:00] PR snapd#6195 closed: snapstate: update fontconfig caches on install [09:00] PR snapd#6218 closed: snapstate: update fontconfig caches on install (2.36) <⚠ Critical> [09:00] good morning [09:10] Hey dot-tobias [09:12] hm finnally, clean installation, no denials, ending up with this: system_u:system_r:unconfined_service_t:s0 root 11016 1 0 09:11 ? 00:00:00 /bin/sh /snap/test-snapd-service/x1/bin/start [09:13] PR snapd#6237 opened: client, store: don't use store from client (use client from store) [09:34] Breakfast time [09:38] * Chipaca joins zyga [09:38] * Chipaca thinks hobbits had the right of it [09:39] Haga [09:40] Haha, yes :-) [09:52] PR snapd#6189 closed: daemon, vendor: bump github.com/coreos/go-systemd/activation, handle API changes (2.36) [10:03] PR snapd#6238 opened: [RFC] many: add minimal SELinux support, refactor the policy [10:05] putting selinux aside for while now [10:08] any PRs needing 2nd reviews? [10:09] mborzecki, you are literally my best friend right now! [10:10] you have _no_ idea how happy I am to see this pull request! [10:11] Son_Goku: haha :) yw, would appreciate if you could find someone more familiar with this stuff to take a look at the policy [10:11] * Son_Goku dances in joy [10:11] * zyga goes to sob in the corner [10:11] :-) [10:11] zyga, this is something I've been asking for two years for! [10:11] Heading home ttyl [10:12] you can't blame me for being overjoyed :) [10:12] I know but I don’t make the schedule [10:12] Son_Goku: hope i got most of the things right, but figuring out the bits was like uhh [10:12] I’m happy to see this too :-) [10:12] mborzecki, yeah I knew it was going to be like that [10:12] Beginning of a long journey [10:12] and the docs are few and useless really :P [10:12] mborzecki, most security subsystems aren't well documented sadly :( [10:13] I'll see if I can get Lukas from the Fedora SELinux team to do a review [10:13] Insecurity by security obscurity [10:13] Son_Goku: yeah, unfortunately true [10:13] some to think of it, SMACK is probably more obscure than SELinux and AppArmor [10:13] yep [10:13] s/some/come/ [10:13] and TOMOYO even more so [10:14] (TOMOYO is what Mageia has enabled, but no one knows what to do with it) [10:14] hahah [10:14] iirc AGL was supposed to use SMACK [10:14] yep [10:15] Son_Goku: o/ ! [10:15] Chipaca: \o [10:15] Son_Goku: when you have a moment I'd like to pick you brain a tiny little bit [10:15] You know [10:15] Chipaca, I have a moment now [10:15] Breakfast downtown is fun and fancy [10:15] Need to do this more often [10:15] zyga: nice, enjoy! [10:15] mborzecki, and the biggest criticism of SMACK is that it's pretty much functionally identical to a minimal SELinux policy [10:16] Son_Goku: you remember, ages ago, when we talked about tracking what users had used snaps, to enable snap-user-enumeration without having to do system-user-enumeration? [10:16] Chipaca, yeah? that was what, a year ago at the rally? [10:16] Son_Goku: you objected to that because you said a user's data should be the user's to control, or something like that? [10:16] yes [10:16] yeah probably more [10:16] actually I don't think that was my only objection [10:16] Son_Goku: now we're again looking at things where we need to enumerate users [10:17] Son_Goku: and the same solution comes up, and so I wanted to revisit your objection to it [10:17] to see if I understood it correctly [10:17] are we talking about ~/snap/* enumeration? [10:17] or the user population/enumeration for services? [10:17] Son_Goku: "all users that have used snaps" [10:18] Son_Goku: like [10:18] Son_Goku: ls /home/*/snap/* but that's a bad way of doing it [10:18] right [10:18] You need a dbus call that does a perl shell call to is [10:18] this? https://forum.snapcraft.io/t/bug-with-cleaning-snap-data-in-home-dirs-proposed-solution/1201 [10:19] Ls, darn shell typos [10:19] Chipaca ^ ? [10:19] zyga: have you looked at the systemd-run change for the profile generation? if not I can do that while waiting for builds [10:19] Son_Goku: yeh [10:19] Son_Goku: i think that's it [10:20] my problem was that the proposal as I understood it would break shared setups and make user data private from the user itself [10:20] Son_Goku: that's one bit I don't understand [10:20] Son_Goku: what's the user data that would be private from the user? [10:20] Son_Goku: the proposal is not to move all user data to /var/whatevs [10:20] well, how I understood it is that data would move from ~/snap to /var/lib/snapd//data [10:21] Son_Goku: but to create a stamp file in /var/whatevs "this user used a snap" [10:21] or something like that [10:22] Chipaca, my only objection there is that it makes network shared users ugly [10:22] Son_Goku: user data would remain unchanged; all this'd do is that 'snap run' would 'touch /var/lib/snapd/user/$USER' before running the thing [10:22] Son_Goku: how does it make network shared users ugly? [10:22] please expand :-) [10:23] well, actually, if it's only that and doesn't effect how data "ownership" and migration occurs, then it's not an issue [10:23] the way it was explained to me at the rally is that we wanted to do "smart things" by doing so [10:23] for example, automatic cleanup of related user-data if the stamp didn't exist [10:23] which would be extremely dumb for networked user case [10:24] er, no, that's the opposite of what I'd want to do [10:24] "related user-data" would not be even looked at if the stamp didn't exist [10:24] PR snapd#6239 opened: packaging/fedora/snapd.spec: fix bogus date in changelog [10:25] mborzecki: it looks like the selinux pr is failing because libselinux not found on centos afaict [10:25] as you say it breaks for networks, it also means that something is enumerating users from the system, which is a no-no [10:25] mvo: thanks, will look into it [10:25] mborzecki: really nice progress btw [10:26] Son_Goku: re-reading that topic now to find the cleanup-of-missing thing to address it there [10:27] mvo: thanks, and sorry for not being too responsive for reviews the last couple of days, didn't want to loose context [10:27] mborzecki, it's because you've disabled libselinux right now [10:28] mborzecki, you currently have selinux disabled for centos builds [10:29] mborzecki: no worries [10:29] oh no, wait, it looks like you've switched it back [10:29] Son_Goku: --enable-selinux is behind %{?with_selinux:..} [10:29] Son_Goku: and the rest is if/endif'ed [10:30] Son_Goku: restored fedora 28 to spread specifically to build it [10:36] omg, with_selinux is always defined :/ [10:36] PR snapd#6240 opened: release: 2.36.2 [10:39] mvo: I have not looked yet [10:39] zyga: ok, I give it a poke [10:43] Thank you [10:47] hmm selinux doesn't like the fontconfig bits [10:53] Son_Goku: https://forum.snapcraft.io/t/bug-with-cleaning-snap-data-in-home-dirs-proposed-solution/1201/14?u=chipaca [10:56] mborzecki, will this work if both apparmor and selinux are available as options (i.e. SUSE distributions?) [10:58] Son_Goku: we'll probably need to disable one, i see that with_selinux is 1 by default [10:58] well, I'm saying can the integration be compiled in? [10:59] because there are folks that use SELinux instead of AppArmor on SLED/SLES, for example [11:00] Son_Goku: you can build both and there's a change it'll work out of the box, the libselinux bits do autodetection and so does libapparmor [11:00] yeah, that's what I was getting at [11:00] Son_Goku: there's always a quesion of refpolicy they use, whether it's the same as fedora [11:01] RH/Fedora and (open)SUSE use the same upstream: fedora-selinux [11:01] actually, of all the distros that offer SELinux support, I think only Debian/Ubuntu don't offer the fedora-selinux variant of the policy [11:02] (and "offer" is a _strong_ word here for Ubuntu... more like didn't purge from Debian impots) [11:02] *imports [11:04] Chipaca: if you've got time, could you have a look at https://github.com/snapcore/snapd/pull/5822 ? [11:04] PR #5822: wrappers: allow user mode systemd daemons [11:04] Son_Goku: mhm, right so there's a change it'll work :) happy to learn how far it gets though [11:04] jamesh: whoops, yes [11:04] mvo, niemeyer, I hope mborzecki's PR for selinux makes it in for the next release, this would drastically improve my confidence in shipping snapd for RHEL/CentOS through EPEL [11:05] I'm actually pretty tempted to not ship until we get this in a release, because this is a *big* improvement across the board [11:05] Chipaca: it should be fairly up to date now: I rebased it recently and spread seems happy with it again [11:05] jamesh: ok [11:05] Saviq, hey, could you try the rawhide image? [11:05] mborzecki, how is transitioning from older policy rules to the new one? [11:05] it works okay? [11:06] Son_Goku: haha, don't be, i see some issues on centos alredy, we need to have smarter runtime detectio of whether the policy is present and the latest bits with fontconfig are causing some issues [11:06] ah [11:06] mborzecki, well, it would at least mean the confinement _does_ something now :) [11:06] not great, but it does something [11:07] Son_Goku: it's only confining snapd and helpers [11:07] but now the framework is in place to confine snaps properly too [11:07] Son_Goku: but there's a path forward i guess at this point [11:07] Son_Goku: at least there are options to explore :) [11:07] yep [11:08] now that we have libselinux integration, we can look at things like mapping CIL and snappy policy knobs to the snappy security HLL [11:09] re [11:11] mvo: sorry for being absent so long, I'm finally home now [11:11] mvo: I will start by adding tests to https://github.com/snapcore/snapd/pull/6233 [11:11] zyga: no worries [11:11] PR #6233: overlord: don't write system key if security setup fails [11:11] then resume with leap fixes [11:23] mvo, hey, I saw 2.36.2 branch has failed [11:23] 2 tests with same error on configure hooks [11:27] cachio: failed in spread? [11:28] cachio: or failed somewhere else? [11:28] mvo, in spread [11:29] cachio: I have not looked yet, does the failure look familiar in any way? [11:29] https://paste.ubuntu.com/p/z7jh7KwJt9/ [11:29] mvo, it is happening on 2.36 family [11:30] mvo, I am already trying to reproduce it [11:40] cachio: no need [11:40] cachio: this is the problem we've been trying to understand recently [11:41] and now I believe we mostly do [11:41] zyga,ah, ok [11:41] zyga, It just failed here :) [11:43] cachio: I did, it seems to have failed to install our deps https://travis-ci.org/MirServer/mir/jobs/461204937 [11:43] I need to add a spread timeout < 50 minutes so it bails out I suppose [11:43] zyga, cachio is it the permission denied bug? [11:43] yes [11:44] cachio, zyga thanks! in this case I hope to push a PR soon with a fix [11:44] mvo, yes [11:44] cannot create temporary directory for /var/lib/snapd mount point: Permission denied [11:44] mvo: does systemd-run play ball on 14.04? [11:44] cachio: yeah, I hope to have something ready before or shortly after lunch [11:44] zyga: I don't know, need to check but if not that would suck(tm) [11:45] zyga: 14.04 is just ~5 more month but still [11:45] mvo: the set of patches I proposed fixes this too [11:45] I will land all the bits needed today [11:46] I don't mind systemd-run being used as well,\ we may have other issues causing system key-based problem [11:47] zyga: hm, you mean 6234 - or more? [11:47] https://github.com/snapcore/snapd/pull/6235 [11:47] PR #6235: overlord,apparmor: new syskey behaviour + non-ignored snap-confine profile errors <⛔ Blocked> [11:48] that's the full set but it is blocked by leap [11:48] https://github.com/snapcore/snapd/pull/6235/commits/15cae44908738b6c8e1814563c0cae727594a3d7 [11:48] have a look at each patch there [11:49] zyga: interessting - and its green, nice. is this reliable, i.e. did you run a couple of times? [11:50] not in that PR but yeah, a few times locally [11:50] feel free to restart it as many times as you like [11:50] it failed only on noise like mount error or store timeout [11:50] great [12:08] zyga: looks like systemd-run is out, a shame [12:08] oh, why? [12:08] zyga: not availalbe on trusty, it has 204 but we need 205 [12:08] 14.04? [12:08] ://// [12:08] bummer [12:08] well [12:08] 4 months [12:08] zyga: yeah, indeed [12:08] and I'm busy writing tests [12:08] oh well, I will shelve the PR [12:08] until then [12:08] I'm happy to finally end 2.36 drama ;) [12:10] zyga: indeed [12:10] zyga: well done! [12:11] zyga, :) [12:21] PR snapd#6239 closed: packaging/fedora/snapd.spec: fix bogus date in changelog [12:22] mvo: systemd-run wha? [12:31] Chipaca: it doesn't exist in 14.04 ? [12:46] mvo: I pushed unit test to https://github.com/snapcore/snapd/pull/6233 [12:46] PR #6233: overlord: don't write system key if security setup fails [12:46] mvo: I will now add a spread test [12:46] have a look please [12:57] off to pick up the kids [13:07] mborzecki: what's the story with https://bugs.launchpad.net/snapd/+bug/1759349 ? [13:07] Bug #1759349: Confinement doesn't work on arch (manjaro) linux [13:10] zyga: sure, looking [13:11] thx [13:12] Chipaca: https://github.com/snapcore/snapd/compare/master...mvo5:systemd-run-security-gen?expand=1 <- the idea was to avoid that apparmor_parser and snap-seccomp processes get killed when we restart snapd [13:12] Chipaca: but a non-starter for now [13:19] mvo: curious how snapd fits into trusty/esm... [13:20] jdstrand: last time we talked about this someone mentioned that snapd would probably not included but that wasn't very official [13:20] jdstrand: gives mvo more gray hair? [13:20] mvo: probably want to talk to joe and amurray. they arer in the process of defining what's in trusty/esm and that is coming from stakeholders [13:21] jdstrand: ok [13:22] mvo: I hadn't really thought that snapd would be in esm, but it seems likely it will have a (much) expanded package set than precise/esm [13:23] mvo: I guess part of this would be looking at data for snapd on trusty and seeing how that maps to esm customers [13:24] mvo: which joe and amurray may need some help with (on the data collection bits) [13:24] jdstrand: makes sense. however the version of systemd (204) there is giving us a headache [13:24] mvo: not trying to give you gray hair, sorry :\ [13:24] * jdstrand nods [13:24] mvo: wrote the spread test, running it now [13:24] I'll make something warm [13:25] zyga: thanks! [13:25] zyga: and sorry for commenting on the wrong PR :/ I commtned on the right now now too [13:25] mvo: with both spread and unit test I'm happy with this being merged into master [13:25] mvo: hah, no worries :) [13:25] least of our problems [13:25] mvo: I wouldn't necessarily consider also upgrading systemd in trusty/esm off the table. there is more flexibility there, so *if* snapd should be included in trusty/esm, perhaps there are things that can be done to make it easier on you [13:25] jdstrand: well, it will be a discussion but trusty is a real burden for us, that should be taken into consideration [13:26] mvo: sure, which is why I wanted to mention that you should let joe and amurray aware of that. you're obviously a stakeholder :) [13:26] PR snapcraft#2380 closed: tests: use autopkgtest to leverage snap testing