=== JanC is now known as Guest55020 === JanC_ is now known as JanC === cachio is now known as cachio_lunch [15:52] sforshee: where can I get that 4.13.0-6.7 kernel? [15:53] sforshee: based on the lxd logs, it looks like something's broken with apparmor profile namespacing, but I'd need to reproduce this myself to see exactly what [15:56] stgraber: ppa:canonical-kernel-team/unstable [15:57] sforshee: for the lxc one, I'm actually wondering if it's not the current resolvconf/networkd mess that's breaking DNS in there. When were those tests run? [15:58] stgraber: today [15:58] hmm, guess I'll have to look at what they broke in artful now... === cachio_lunch is now known as cachio [16:31] jjohansen: some snapd adt tests are failing with 4.13, and all the failures have the message "Failed to query AppArmor policy: Permission denied." Any idea what's going on there? [16:31] jjohansen: bug 1713103 [16:31] bug 1713103 in snapd (Ubuntu) "snapd 2.27.3+17.10 ADT test failure with linux 4.13.0-6.7" [Undecided,New] https://launchpad.net/bugs/1713103 [16:34] sforshee: are you able to run commands on that test machine? if so, the output of `ls -al /sys/kernel/security/apparmor/.access` would be hadny [16:35] s/hadny/handy/ [16:35] sforshee: oh, I've got yesterday's linux-next kernel running in a VM [16:35] on artful: [16:35] -rw-rw-rw- 1 root root 0 Aug 15 17:38 /sys/kernel/security/apparmor/.access [16:36] (artful kernel 4.11.0-13.19-generic) [16:36] on linux-next: [16:36] -rw-r----- 1 root root 0 Aug 24 21:26 /sys/kernel/security/apparmor/.access [16:37] tyhicks: those were adt tests so no I don't have access [16:37] looks like the apparmor kernel query interface was upstreamed with different file permissions than what was previously in ubuntu [16:38] sforshee: no worries - I'll update the bug with my findings so that jjohansen knows the problem when he starts his day [16:38] tyhicks: thanks, appreciate it! [17:43] tyhicks, sforshee: tracked down the LXD adt failure with 4.13, the problem is a change of apparmor syntax to represent a stacked profile [17:44] before 4.13: [17:44] lxd-aatest_//&:lxd-aatest_://unconfined (27047) [17:44] after 4.13: [17:44] lxd-aatest_//&:lxd-aatest_:unconfined (23835) [17:44] this is tripping our test for ":://unconfined" [17:46] I'll send an upstream tweak for our testsuite so that it supports both syntaxes [17:47] jjohansen: ^ was that intentional? [17:48] tyhicks: give me a sec [17:49] no worries, just making sure you saw stgraber's investigation [17:49] jjohansen, tyhicks: If this is expected, I'll send this upstream: http://paste.ubuntu.com/25390829/ [17:49] which should make both our policy and test support both syntaxes [17:50] tyhicks: the switch from :ns://profile -> :ns:profile was intential [17:50] both formats have always been valid [17:50] I guess you weren't around when I asked the question [17:50] it came down to readablity [17:51] I suppose it is nice to save a couple chars since that string length is limited [17:51] well yes there is that too [17:51] jjohansen: do we need to have both syntaxes listed in change_profile? [17:52] stgraber: ? you can use either, they are both valid, always have been [17:52] jjohansen: right now we generate a profile which contains: "change_profile -> lxd-aatest_//&:lxd-aatest_://*" [17:52] oh, you mean the documentation? yes they should be [17:53] Will that match someone doing a change profile to "lxd-aatest_//&:lxd-aatest_:unconfined"? [17:53] or is the check done against the provided string as it came from the user [17:54] stgraber: the check is should be post parse [17:54] but it is possible there is a bug [17:56] ok [17:56] so, I would say that is a bug on our end, I'll take a look [17:57] I don't know that there is a bug, was just wondering whether we need to allow both syntaxes in the profile so that we don't end up with one being blocked for our users [17:57] anyway, I've confirmed that listing both syntaxes doesn't cause problems, so we'll just go with that, safer that way [18:00] stgraber: yes its a bug, but at least there is a work around of listing both [19:10] jjohansen, tyhicks: also some apparmor test failures here - https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-canonical-kernel-team-unstable/artful/amd64/l/linux/20170825_162923_61ef2@/log.gz [19:13] jjohansen: looks like pivot_root regression test failures [19:13] probably related to the lack of profile transition functionality [19:26] sforshee: yes there are a few regression test changes to go with the kernel, we need to get those pushed out [19:27] there are the pivot root transitions, a couple of query tests going from xpass to pass [19:27] jjohansen: ack, thanks for taking a look [19:27] the longpath fix which we already have in ubuntu [19:27] xpass -> pass [19:27] nice [19:28] jjohansen: I think bug 1713103 is probably the most important failure right now [19:28] bug 1713103 in linux (Ubuntu) "snapd 2.27.3+17.10 ADT test failure with linux 4.13.0-6.7" [High,Triaged] https://launchpad.net/bugs/1713103 [19:28] jjohansen: I did some quick triage, left my findings in the bug, and then assigned it to you [19:28] ack === tjaalton_ is now known as tjaalton [21:18] sforshee: we spoke one or two weeks ago about the need to target both the 4.12 and 4.13 kernels for artful backports [21:18] sforshee: however, I'm just getting around to the backport [21:18] sforshee: do I still need to target both or is 4.13 sufficient? [21:19] * tyhicks isn't sure when 4.13 is expected to land [22:38] before 4.14! [22:40] .12 has rc7 before going 'stable'. .11 had rc8, .10 had rc8. we're at 4.13.6, i'll give it another one or two rc's. [22:42] that's unless hpe ilom ent into kernel space recently ;-) [22:44] ... or someone actuall ylooked at inifiniband code from an infinite perspective. [23:17] sforshee: nvm, I went ahead and backported to 4.12 and tested both 4.12 and 4.13. Patches sent to the kernel-team mailing list.