[15:52] <stgraber> sforshee: where can I get that 4.13.0-6.7 kernel?
[15:53] <stgraber> 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] <sforshee> stgraber: ppa:canonical-kernel-team/unstable
[15:57] <stgraber> 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] <sforshee> stgraber: today
[15:58] <stgraber> hmm, guess I'll have to look at what they broke in artful now...
[16:31] <sforshee> 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] <sforshee> jjohansen: bug 1713103
[16:34] <tyhicks> 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] <tyhicks> s/hadny/handy/
[16:35] <tyhicks> sforshee: oh, I've got yesterday's linux-next kernel running in a VM
[16:35] <tyhicks> on artful:
[16:35] <tyhicks> -rw-rw-rw- 1 root root 0 Aug 15 17:38 /sys/kernel/security/apparmor/.access
[16:36] <tyhicks> (artful kernel 4.11.0-13.19-generic)
[16:36] <tyhicks> on linux-next:
[16:36] <tyhicks> -rw-r----- 1 root root 0 Aug 24 21:26 /sys/kernel/security/apparmor/.access
[16:37] <sforshee> tyhicks: those were adt tests so no I don't have access
[16:37] <tyhicks> looks like the apparmor kernel query interface was upstreamed with different file permissions than what was previously in ubuntu
[16:38] <tyhicks> sforshee: no worries - I'll update the bug with my findings so that jjohansen knows the problem when he starts his day
[16:38] <sforshee> tyhicks: thanks, appreciate it!
[17:43] <stgraber> 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] <stgraber> before 4.13:
[17:44] <stgraber>    lxd-aatest_</var/lib/lxd>//&:lxd-aatest_<var-lib-lxd>://unconfined (27047) 
[17:44] <stgraber> after 4.13:
[17:44] <stgraber>    lxd-aatest_</var/lib/lxd>//&:lxd-aatest_<var-lib-lxd>:unconfined (23835) 
[17:44] <stgraber> this is tripping our test for ":<profile>://unconfined"
[17:46] <stgraber> I'll send an upstream tweak for our testsuite so that it supports both syntaxes
[17:47] <tyhicks> jjohansen: ^ was that intentional?
[17:48] <jjohansen> tyhicks: give me a sec
[17:49] <tyhicks> no worries, just making sure you saw stgraber's investigation
[17:49] <stgraber> jjohansen, tyhicks: If this is expected, I'll send this upstream: http://paste.ubuntu.com/25390829/
[17:49] <stgraber> which should make both our policy and test support both syntaxes
[17:50] <jjohansen> tyhicks: the switch from :ns://profile -> :ns:profile was intential
[17:50] <jjohansen> both formats have always been valid
[17:50] <jjohansen> I guess you weren't around when I asked the question
[17:50] <jjohansen> it came down to readablity
[17:51] <tyhicks> I suppose it is nice to save a couple chars since that string length is limited
[17:51] <jjohansen> well yes there is that too
[17:51] <stgraber> jjohansen: do we need to have both syntaxes listed in change_profile?
[17:52] <jjohansen> stgraber: ? you can use either, they are both valid, always have been
[17:52] <stgraber> jjohansen: right now we generate a profile which contains: "change_profile -> lxd-aatest_</var/lib/lxd>//&:lxd-aatest_<var-lib-lxd>://*"
[17:52] <jjohansen> oh, you mean the documentation? yes they should be
[17:53] <stgraber> Will that match someone doing a change profile to "lxd-aatest_</var/lib/lxd>//&:lxd-aatest_<var-lib-lxd>:unconfined"?
[17:53] <stgraber> or is the check done against the provided string as it came from the user
[17:54] <jjohansen> stgraber: the check is should be post parse
[17:54] <jjohansen> but it is possible there is a bug
[17:56] <stgraber> ok
[17:56] <jjohansen> so, I would say that is a bug on our end, I'll take a look
[17:57] <stgraber> 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] <stgraber> anyway, I've confirmed that listing both syntaxes doesn't cause problems, so we'll just go with that, safer that way
[18:00] <jjohansen> stgraber: yes its a bug, but at least there is a work around of listing both
[19:10] <sforshee> 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] <tyhicks> jjohansen: looks like pivot_root regression test failures
[19:13] <tyhicks> probably related to the lack of profile transition functionality
[19:26] <jjohansen> sforshee: yes there are a few regression test changes to go with the kernel, we need to get those pushed out
[19:27] <jjohansen> there are the pivot root transitions, a couple of query tests going from xpass to pass
[19:27] <sforshee> jjohansen: ack, thanks for taking a look
[19:27] <jjohansen> the longpath fix which we already have in ubuntu
[19:27] <tyhicks> xpass -> pass
[19:27] <tyhicks> nice
[19:28] <tyhicks> jjohansen: I think bug 1713103 is probably the most important failure right now
[19:28] <tyhicks> jjohansen: I did some quick triage, left my findings in the bug, and then assigned it to you
[19:28] <jjohansen> ack
[21:18] <tyhicks> 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] <tyhicks> sforshee: however, I'm just getting around to the backport
[21:18] <tyhicks> 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] <tomreyn> before 4.14!
[22:40] <tomreyn> .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] <tomreyn> that's unless hpe ilom ent into kernel space recently ;-)
[22:44] <tomreyn> ... or someone actuall ylooked at inifiniband code from an infinite perspective.
[23:17] <tyhicks> 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.