=== amurray` is now known as amurray [05:06] morning === chihchun_afk is now known as chihchun [06:13] mvo: morning, i'm working with interfaces repo now, do you know if plug/slot ordering is of importance there? [06:17] mborzecki: unfortunately I don't [06:17] mborzecki: what are we currently doing? [06:18] mvo: the Slots()/Plugs() methods of repo do sorting by plug and snap name, with instance names looking like foo_bar the plugs/slots from instance snaps are always sorted after the regular ones [06:20] mborzecki: aha, right. I think its fine but lets validate with zyga [06:20] mvo: ok [06:21] btw. DeepEquals tends to blow up in those repo test when there's a mismatch [06:21] mborzecki: blow up in what way? [06:21] mborzecki: isn't the new diff stuff helping? [06:21] mborzecki: or not good enough? [06:21] mvo: the test binary is oom killed [06:21] mborzecki: woah [06:21] mvo: oh, maybe it's the diff [06:23] sie 09 08:09:15 corsair kernel: Out of memory: Kill process 27003 (interfaces.test) score 685 or sacrifice child [06:23] sie 09 08:09:15 corsair kernel: Killed process 27003 (interfaces.test) total-vm:8926256kB, anon-rss:8325200kB, file-rss:4kB, shmem-rss:5400kB [06:26] Good morning [06:27] zyga: hey, how's flock? [06:27] mvo, mborzecki: how can I help? [06:27] mborzecki: very interesting [06:27] I will write my day one report after breakfast [06:28] zyga: quick question, do you know whether the ordering of results in interface repo .Plugs()/Slots() method of impotance? with instances named foo_bar they get always sorted after non instance-keyed snaps [06:29] It was just designed to be deterministic [06:29] If you want to change that please look at how the results are used [06:29] Some code relies on this fact === iliv_ is now known as iliv [06:59] * zyga uploads fedora29 snap again [06:59] (with some workarounds) [07:00] ok, it just failed on type: base and some setuid root executables [07:00] mvo: I'll neuter all the +s flags for now [07:00] mvo: and re-upload [07:01] would you be OK acking the snap with just the type: base violation? [07:04] zyga: ok [07:04] zyga: sure, should be ifne === chihchun is now known as chihchun_afk [07:11] mvo: https://dashboard.snapcraft.io/snaps/fedora29/revisions/3/ [07:11] mvo: I don't know how to request manual review otherwise [07:12] zyga: its in [07:12] awesome, thank you! === pstolowski|afk is now known as pstolowski [07:17] mornings [07:19] pstolowski: heya [07:32] mvo: hey! Can you upload the pi3 image somewhere for me to look at? Need to confirm something [07:32] mvo: a fresh pi3 image at best [07:32] (unconfigured yet) [07:41] sil2100: sure, let me look at this [07:45] mvo: hey, [07:46] mvo_: can you please do a small test for me [07:46] mvo_: would you mind trying the fedora29 snap (--edge) and then hello-fedora snap (stable) to see if it works on your system [07:50] zyga: http://paste.ubuntu.com/p/97KmYZft6S/ === Fearful is now known as Guest30827 [07:50] woah, interesting [07:50] sil2100: uploading [07:50] thank you, I need to think about this now [07:51] mvo: did you have any magic environment set up, LD_PRELOAD for instance? [07:51] zyga: I'm not aware of any, there is a defualt LD_PRELOAD for some window decration stuff but that is harmless [07:52] aha [07:52] yay, the first time when we have incompatible ABI signatures :D [07:52] the path is interesting [07:52] zyga: I think if you symlink /var/lib/snapd/snap to /snap in the fedora base things will work [07:52] why: /var/lib/snapd/snap/hello-fedora/4/meta/snap.yaml [07:52] zyga: because snap-exec detects its inside fedora [07:52] zyga: and it expects the fedora layout [07:52] mvo, that shouldn't be necessary, though? [07:53] hmm [07:53] zyga: thats my guess at least [07:53] zyga: mvo is actually correct [07:53] * zyga explores [07:53] we actually discovered this the first time I was working on this last year [07:53] that's why mvo sent me a patch for my tool to actually add that [07:53] Son_Goku: I did? woah, I don't even remember [07:53] yeah [07:54] I'm not sure that's really the case yet [07:54] the one and only time you've ever sent me a patch ;) [07:54] *cough* [07:54] * mvo hugs Son_Goku [07:54] mvo: thank you! [07:54] mvo: does snap run --shell hello-fedora also fail? [07:54] mvo, this was all you: https://gitlab.com/Conan_Kudo/snapcore-mkrpmdistcoresnap/blob/master/mkrpmdistcoresnap#L122-132 ;) [07:54] zyga: yes, in the same way [07:54] ok, thank you [07:54] * zyga tries something [07:55] sil2100: please try http://people.canonical.com/~mvo/tmp/pi-kiosk.img [07:57] it's a bug in snap-confine [07:57] I will work around it for now [07:58] uh [07:59] not easy [07:59] * zyga needs to think [08:06] zyga: isn't that the same thing that we had on amazon? [08:10] zyga: fwiw 'Hello Fedora!' here on arch [08:14] pstolowski: https://github.com/snapcore/snapd/pull/5614 [08:16] mborzecki: will do [08:17] mborzecki: thank you :) [08:17] mborzecki: I think there are issues when we mis-identify things in snap-confine [08:17] my preference is that all bases agree that /snap exists [08:17] not as a symlink [08:17] and snaps are mounted there [08:18] oh well [08:18] I need to move now, I'll check back soon [08:19] zyga: sounds like we could teach s-c a new trick [08:32] What is on your mind mborzecki ? [09:08] 2018-08-09 09:04:40 Cannot allocate google:ubuntu-16.04-32: cannot perform Google request: Get https://www.googleapis.com/compute/v1/projects/computeengine/zones: oauth2: cannot fetch token: Post https://accounts.google.com/o/oauth2/token: net/http: TLS handshake timeout [11:10] stgraber: hey, if you are around, is there a way to set "lxc.aa_profile=unconfinged" with lxd 3.0? trying my detection code currently and my machines are all bionic already === Mikaela_ is now known as Mikaela === Mikaela_ is now known as Mikaela [11:24] pstolowski: https://github.com/snapcore/snapd/pull/5616 ifacestate fix [11:24] looking [11:27] +1 [11:37] o/ [11:38] * Son_Goku waves [11:57] another simple review https://github.com/snapcore/snapd/pull/5619 (cc pstolowski ) [11:59] mborzecki: on it, does it pass all unit tests? [12:01] pstolowski: yes [12:01] awesome [12:01] i was afarid we accidently relied on it somewhere :/ [12:02] heh, i hope not :) === pstolowski is now known as pstolowski|lunch [12:25] mborzecki: hey [12:26] zyga: hm? [12:26] I have a patch coming up, just fighting github auth [12:26] one moment :) [12:26] t's the fix we were talking about [12:26] ah, ok [12:38] mborzecki: https://github.com/snapcore/snapd/pull/5620 [12:38] have a look [12:38] with this the hello-fedora snap should work on ubuntu [12:44] zyga: yeah, +1 as far as I'm concerned [12:51] I'm adding a spread test [12:51] and one more patch [12:56] mborzecki: I pushed two more patches [12:56] can you sanity check them please [13:27] niemeyer: once you have some time it would be good to update spread snap, it's out of date and cannot even parse our spread.yaml now === pstolowski|lunch is now known as pstolowski [13:49] pstolowski: spread test for interfaces https://paste.ubuntu.com/p/PmJdPvR2hp/ (amazingly this all works locally, even with the content provider) [13:50] mborzecki: nice, will take a look, ty [13:52] mborzecki: really nice :D [13:52] can someone manually run tests against https://github.com/snapcore/snapd/pull/5620 [13:53] for some ballpark works/doesn't qualification [13:53] ubuntu + fedora + that one new test [13:56] I don't have a working spread setup here [13:56] I'll check back later in case anyone does o/ [13:57] zyga: /proc/self/attr/current is "unconfined" in my container when it can't load apparmor profiles with apparmor_parser -a [13:58] zyga: I will use a workaround and prepare a pr [13:58] mvo: lxc.apparmor.profile=unconfined [14:00] stgraber: thank you! [14:02] zyga: running on ubuntu 18.04, fedora & arch [14:03] mborzecki: thank you [14:04] mvo: interesting [14:04] mvo: and when you load a profile, what happens? [14:04] what is the error you get [14:04] mvo: and what is the profile of snapd from _outside_ [14:04] or profile of bash inside a container [14:05] stgraber: does that also disable stacking or is stacking controlled with a separate knob? [14:07] zyga: that also disables stacking [14:08] stgraber: I see [14:08] stgraber: does lxd use something other than apparmor? [14:08] seccomp? [14:08] zyga: so in that case, you're not confined but also don't have mac_admin/mac_override so can't affect the host apparmor namespace [14:08] ah [14:08] I see [14:08] zyga: we have seccomp too, yeah, and caps [14:08] and libcap cannot tell that? [14:08] I mean, can we ask the kernel about our caps/ [14:08] instead of loading a profile [14:08] zyga: hm, from outside it is also unconfined afaict [14:09] mvo: yes, that's consistent and expected based on what stgraber said [14:12] zyga: 2018-08-09 16:12:05 Successful tasks: 3 [14:21] mborzecki: thank you! [14:21] mvo: another data point: gconv translation functions for fringe encodings are huge [14:22] and I suspect we need at most 2-3 [14:31] pstolowski: i've pushed the spread to the integration branch right here https://github.com/snapcore/snapd/pull/5596/commits/f846ea192d89f98c4b8c8b4036a935ef47589e53 [14:37] mvo: can you please ensure that the patch I sent is in 2.35 [14:37] it's pretty essential for now [14:39] Hey mvo, did you manage to make any progress on discovering apparmor capabilities in snapd? [14:40] kyrofa: yes [14:40] kyrofa: I have a reproducer and work on code now [14:44] mvo, ah, wonderful!! [15:32] Chipaca: fun bug: snap refresh --jailmode doesn't [15:32] it's not switching it [15:32] zyga: fun bug: neither does --devmode nor --classic [15:32] zyga: you could almost say it might not be a bug :-D [15:32] Chipaca: snap install --jailmode foo refuses to work when foo is classic! [15:32] zyga: (OTOH if we don't do anything maybe we should error or sth) [15:33] zyga: at your request iirc [15:33] Chipaca: just dropping a note in case I forget, live feedback from flock [15:33] :-) nice [15:33] zyga: keep 'em coming [15:36] mvo: hmmm, would you be able to somehow get on a pi3 core18 running system and find me all the .yaml files that are on there? Since something's really fishy around here [15:38] mvo: I unpacked and checked the image you gave me and found nothing suspicious - the only way console-conf could put the 'set-name' into the config is by copying it over from the source configs [15:38] mvo: and there's just one source config on the squashfs that I see and it's correct [15:38] hmm, let me try one more thing though [15:39] sil2100: this bug prevents logging in so its slightly tricky, what I did was pulling out the sd card and mount it after I interacted with the system. does that work or are there still no files in there if you do that? [15:40] mvo: wait one more moment, I'll get back to you once I check something else out on the filesystem [15:41] kyrofa: hey [15:42] kyrofa: can you please try building github.com/davdunc/aws-cli-snap please [15:42] kyrofa: we're hitting an issue where apt fails on lack of --allow-unauthenticated [15:42] kyrofa: is there a cache with a choot container or something [15:43] kyrofa: can we clean something on the host [15:43] kyrofa: to "maybe" fix it? [15:50] mvo: hi! are you planning a 2.34.4? this is in 2.34 branch, but not 2.34.3 snap/deb: https://github.com/snapcore/snapd/pull/5579 [15:55] jdstrand: the plan is to have a beta of 2.35 soon (today or tomorrow moring). no further plans for 2.34 unless something critical somes up [15:55] well, that works too [15:56] cachio: the lxd test currently only runs on 16.04-32 - can we enable it again on more arches? [15:56] mvo: I've got some profile updates that I'd like in 2.35. when do you need them by? [15:56] mvo: early next week is best for me, but if required, I can do it sooner [15:56] jdstrand: the first beta goes out this week but profile updates are fine until it hits candidate so at least a week [15:56] jdstrand: next week is fine [15:57] ok, perfect [15:57] mvo: thanks! [15:57] jdstrand: we will just need to cherry-pick them [15:57] jdstrand: thank you [15:57] kyrofa: fix is ready I'm just working on the spread test now but manual testing looked good [16:01] mvo: that socketcall PR. should I target it to 2.35 too? it isn't pressing to me personally so long as it gets into trunk, but not sure of the relationship between 2.35 and core18 images [16:03] jdstrand: please target it [16:04] mvo: ok [16:04] mvo, that's great! Let me know if I can help [16:05] jdstrand: what apparmor permissions are needed for doing "aa_kernel_interface_new()"? [16:08] mvo, I forgot to share the errors [16:08] https://paste.ubuntu.com/p/JRt3rkPTgY/ [16:08] cachio: ta [16:09] mvo, I am working in other set based on test fails === pstolowski is now known as pstolowski|afk [16:10] * Chipaca kicks travis [16:11] ok, i'm off to the shops, I'll be back later to see if it's progressed [16:11] ttfn [16:20] mvo: otoh, I don't know. the minimal most restricted set of rules on a 4.15 kernel is: https://paste.ubuntu.com/p/FjSxZ5pbwb/ [16:20] mvo: you could reduce the /sys/kernel/security/apparmor/... down to '/sys/kernel/security/apparmor/{,**} r,' [16:21] but I did it that way to see all the accesses [16:21] jdstrand: thanks, I will push a PR shortly and will ask for advice [16:22] mvo: now, that is a simple 'run apparmor_parser under apparmor' test [16:22] jdstrand: https://github.com/snapcore/snapd/pull/5621 <- is where I need it, hope this all makes sense. and also I wonder if there is a better way [16:23] mvo: DAC and profile stacking are going to be involved for more complicated things [16:23] jdstrand: maybe I can use aa-status instead of apparmor_parser in the go code, that seems to be less noisy [16:24] jdstrand: yeah, this is really just so that we can detect if all looks well but in fact its not [16:25] mvo: aa-status is definitely recommended, cause it will be updated to support new things. do note, it is python3 [16:25] jdstrand: yeah, thats downside, I could create a small helper c-binary around aa_kernel_interface_new() [16:25] it is interestingly bi-lingual and will run under py2. but that is neither here nor there and just fun trivia [16:25] jdstrand: :) [16:27] mvo: aa-status is not actually terribly smart. does it return non-zero in the case you are looking at? [16:28] mvo: I ask, cause you could implement its dumb test in Go I suspect (though again, you'd take on the maintenance burden of that) [16:30] mvo: sucks that I don't have a raspi3 - I know that's probably a lot to ask, especially because of the size, but you think it would be possible for you to tar up the contents of the filesystem from the SD card after the invalid config is up and share it somewhere? Might make things easier for me to debug [16:32] sil2100, you should really get one and expense the 30€ :) [16:32] ogra: I think I'll just do that indeed, not the first time I'm poking on the raspi3 [16:32] hmmm [16:33] * sil2100 goes check on that [16:33] its not like it is super expensive or so [16:35] jdstrand: thanks, I will think a bit about it [16:36] sil2100: lets debug that tomorrow then, I can help. plus buying/expensing one is probably fine [16:36] kyrofa: pr#5621 but its a bit of a can of worms, so not sure if this will not need some more iterations [16:37] mvo: is it only that you don't have mac_admin? [16:37] they probably only gave him pc_admin :P [16:38] (SCNR .... the heat and such) [16:55] mvo: see my comments in the PR and this: https://paste.ubuntu.com/p/cTTqxwJpqf/ [16:56] jdstrand, this brief conversation might be helpful for reference: https://irclogs.ubuntu.com/2018/08/08/%23ubuntu-devel.html#t14:35 [16:57] (regarding mac_admin) [17:01] jdstrand: I'm not sure this is observable from inside the container [17:01] Hey [17:02] jdstrand: I tried looking at /proc/self/status and CapEff in there and AFAICT I have the right bits [17:02] * zyga is resting after a very hot and busy day [17:02] mvo: you mean the kernel is telling you that you have mac_admin but you do not? [17:03] jdstrand: correct, again with the caveat that I'm not an expert on this (yet) [17:03] jdstrand: I have not used pscap for this, just the status file in proc but let me check with pscap [17:03] mvo: well, I'm not either, but that sounds wrong... [17:03] jdstrand: note this is inside an lxd container [17:03] * zyga tunes in [17:04] jdstrand: and lxd itself restricts this cap (again AIUI) [17:04] tyhicks: hi! would it surprise you if inside a container, it reports having mac_admin but in reality, it does not? [17:04] Kernel bugs, you tiny little kernel bugs, where are you? ;-) [17:04] tyhicks: (see backscroll for context) [17:06] jdstrand: I just ran pscap and mac_admin is availalbe for everything. yet when I try to load a profile (empty) I get permission denied [17:06] jdstrand: see the PR for how to construct such a test case, but its pretty simple [17:06] tyhicks: mvo's observance sounds like a bug ^. is it? [17:07] observation* [17:08] mvo: so, loading a profile is certanly one way to do it, but that will spam the logs [17:08] mvo: I suspect there is an easier way [17:09] jdstrand: (very) open for ideas [17:09] let me try some things [17:10] I could see having mac_admin in the container and the wrapping apparmor profile denying it, but I thought the container was unconfined... maybe I misread somethign [17:10] tyhicks: fyi ^ [17:11] jdstrand: the container is unconfined [17:11] mvo: is this a new issue or are you trying to enable some tests that never ran/always failed before [17:11] jdstrand: aiui lxd will take away (drop) cap_mac_admin (and override) in this case when running things [17:11] jdstrand: this is an old bug but we never tried to fix it [17:11] jdstrand: it was not even understood [17:11] oh, yeah, well, that would explain it I guess [17:12] jdstrand: we got reports about this from various people but never looked into it until recently when iirc mborzecki and kyrofa at the same time came up with this failure [17:12] Yeah, this is an unprivileged lxc container with apparmor disabled, lxc doesn't want to make the host apparmor available [17:13] Which makes sense given that it's still unprivileged [17:16] tyhicks: nm [17:49] mvo: I think if you open() /sys/kernel/security/apparmor/.remove, then write something valid (eg, "profile canary-blah {}"), then close the fd, you'll get permission denied [17:50] mvo: ie, use lowlevel calls to perform an atomic write on a profile that isn't loaded in the kernel [17:51] mvo: err, ie, use lowlevel calls to perform an atomic write on the .remove file to try to remove a profile that isn't loaded in the kernel [17:54] mvo: with mac_admin, you'd get ENOENT [17:56] mvo: eg: [17:56] Mvo: I would suggest to use a profile name like snap.system.canary [17:56] $ sudo bash -c "echo canary >/sys/kernel/security/apparmor/.remove" [17:57] bash: line 0: echo: write error: No such file or directory [17:57] [1] [17:57] $ sudo aa-exec -p test -- bash -c "echo canary >/sys/kernel/security/apparmor/.remove" [17:57] bash: line 0: echo: write error: Permission denied [17:57] [1] [17:57] Because we “own” that namespace [17:57] zyga: do we own the 'system' snap? [17:58] zyga: I mean, maybe snap.core.canary [17:58] Yes [17:58] We reserved system [17:58] well, whatever, so long as it doesn't accidentally remove something [18:01] * zyga cannot stand the weather today [18:01] It’s 8PM but the temperature outside is the same as at noon [18:02] zyga, tail end of summer, hang on [18:02] Almost through [18:02] I hate it, too [18:11] zyga, hey [18:11] I see a weird error on core18 [18:11] some tests [18:11] jdstrand: thanks for your suggestion in the PR - should I do the loading in the C code as well or just in the go code? [18:12] fail when we do MATCH 'xxx' < file [18:12] zyga, but if we do cat file | MATCH 'xxxx' [18:12] works [18:12] zyga, any idea which could be the reason? [18:12] cachio: that sounds like the subshell issue we found some days ago [18:13] cachio: https://github.com/snapcore/spread/pull/67 maybe? [18:13] mvo, ahhhh [18:13] mvo: actually, I just found something even simpler [18:13] https://github.com/snapcore/snapd/pull/5621/comment#issuecomment-411848548 [18:13] mvo, let me test it, I already have the spread with your change [18:13] mvo: ^ [18:14] jdstrand: nice! [18:14] jdstrand: thats easy enough from both C and go [18:14] jdstrand, nice find [18:16] mvo: yes. what is interesting is that a mac_admin denial is not triggered by that (you don't need mac_admin to read that file) [18:16] mvo: but you do need to be root [18:16] mvo: (even though the perms are listed as 444) [18:16] mvo, this fix the issue [18:16] thanks [18:17] jdstrand: interessting. is this a reliable test. you write that you don't need mac_admin to read that file? [18:17] mvo: so this is DAC that is preventing it. while I'm root in the container, the container is running as non-root. non-root can't access the file [18:18] jdstrand: my tst container runs as root - or are you saying it drops root at some point? [18:18] jdstrand, does that test pass in a normal, unpriv container? [18:18] (without apparmor disabled) [18:18] kyrofa: yes [18:19] root@xenial-unconfined:~# cat /sys/kernel/security/apparmor/profiles [18:19] cat: /sys/kernel/security/apparmor/profiles: Permission denied [18:19] But you're still not root [18:19] that's true. interesting [18:19] that also feels like a bug [18:19] jdstrand: I like this because a) simple b) no log spam - is it reliable, i.e. I hope it won't be "fixed" at some point :) [18:20] jdstrand: but I would definitely like to have a way that avoids the log spam [18:20] mvo: the .remove of a non-existent profile would avoid log spam [18:20] mvo: and is a true mac_admin test [18:21] jdstrand: cool, then I will go with this - should I do the same in the C code? [18:21] jdstrand: actually I think there is no log spam there [18:21] mvo: what do you mean no log spam? [18:21] where? [18:22] jdstrand: will update the (go) code now to use the removal of a non-exiting profile - I will just create a random strings [18:22] jdstrand: I had to update snap-confine as well [18:22] jdstrand: to detect if apparmor is fully usable [18:23] jdstrand: but the C code does not log anything so that should be ok(?) [18:23] mvo: I'm confused by this conversation, but if you write a non-existent profile name to /sys/kernel/security/apparmor/.remove, you will get an ENOENT when have mac_admin, and EPERM or EACCES if you don't. in neither case will there be a log entry [18:24] (I say 'or' cause otoh I don't know which) [18:25] mvo: in your current implementation, you are successfully loading a valid profile. that will create an entry in the audit subsystem. then you remove it, and it will create a second entry for that [18:26] mvo: I was wondering why you are updating both snap-confine and go code? [18:29] jdstrand: sorry for the confusion. the go check is needed to ensure that snapd does not try to load the apprarmor profiles it generates into the kernel (which will fail) [18:29] and snap-confine is for change_onexec [18:30] jdstrand: the snap-confine code needs updating because it has its own detection for apparmor and if it detects that is has apparmor it will set aa_change_on_exec() which will fail too [18:30] since the profile isn't there [18:30] right [18:30] ok [18:30] jdstrand: well, even if it is it can't change it, right? [18:30] jdstrand: or does not not require privs? [18:30] jdstrand: in any case, yes, its not there as well :) [18:30] mvo: it doesn't need mac_admin to change profiles, but it can't change profiles if the profile isn't loaded [18:31] jdstrand: gotcha, thanks! [18:31] mvo: the .remove that you are going with (which I think is fine), is a bit of a hack. can you add a comment on why you are doing it that way? [18:31] jdstrand: sure [18:31] thanks [18:41] mvo, in core18 when we get the snap env [18:41] the SNAP_INSTANCE_xxx are not there [18:41] this is making fail the test snap-env [18:57] jdstrand: I pushed an update to the PR [18:59] jdstrand: I will read comments in the PR - thanks for all your help! [18:59] * mvo calls it a day [19:31] why is ubuntu-image crashing lately? === phillid is now known as Guest12690 [19:58] stgraber: hey, on a 4.15 kernel (bionic), if I have an apparmor denial in the the container's policy, where would I see that logged? journald isn't showing me what I expect [19:59] jdstrand: I'd expect it to hit the kernel log which may or may not be readable by the container [19:59] ok, I was looking on the host [20:01] stgraber: otoh, with lxc.apparmor.profile=unconfined, should I see that in the container? [20:01] well, with that in place you shouldn't be able to get any denial because there'd be no apparmor in place [20:02] stgraber: but there is a lxd-xenial-unconfined profile. what is that for? [20:03] when you use raw.lxc you play behind LXD's back, so LXD doesn't know the profile it's generating won't be used [20:03] I see [20:04] stgraber: ok, do you have an idea why cat /sys/kernel/security/apparmor/profiles gets an EACCES with: [20:04] config: [20:04] raw.lxc: | [20:04] lxc.apparmor.profile=unconfined [20:04] lxc exec xenial-unconfined -- cat /sys/kernel/security/apparmor/profiles [20:04] cat: /sys/kernel/security/apparmor/profiles: Permission denied [20:04] is that container unprivileged? [20:04] stgraber: yes [20:05] then that's normal [20:05] unprivileged users can't read that file [20:05] but they can [20:05] stgraber@castiana:~$ cat /sys/kernel/security/apparmor/profiles [20:05] cat: /sys/kernel/security/apparmor/profiles: Permission denied [20:05] there is something weird going on. let me paste [20:06] jdstrand: if you're in a normal container, you can because an apparmor namespace is setup [20:06] jdstrand: well, root in the container can [20:06] but in this case, you're in an unprivileged container without an apparmor namespace, so you have as much right as a nobody user on the host [20:07] stgraber: https://paste.ubuntu.com/p/4FzwpSFs2B/ [20:08] stgraber: ah, ok, that explains it then [20:08] stgraber: thanks! [20:27] jdstrand: hey [20:27] jdstrand: can you please (if possible) whitelist fedora29 as "type: base" [20:29] jdstrand: I pushed a pair of revisions just now [20:29] jdstrand: if you cannot make that permanent please at least ack those two [20:39] zyga: who is responsible for that base? [20:39] jdstrand: currently just me, we are working with the fedora server SIG to transfer it over and they are happy to take it [20:39] jdstrand: I just need it for a talk tomorrow [20:40] (I'm at a fedora conference this week) [20:41] jdstrand: it won't go to stable before the hand off [20:41] zyga: I'll approve it since you did it, but we have no process surrounding base snap reviews, so that should be discussed in the forum with niemeyer's input [20:42]