[apparmor] [PATCH] profiles: Grant access to systemd-resolved in the nameservice abstraction
John Johansen
john.johansen at canonical.com
Thu Oct 13 14:25:56 UTC 2016
On 10/12/2016 02:55 PM, Christian Boltz wrote:
> Hello,
>
> Am Mittwoch, 12. Oktober 2016, 14:31:13 CEST schrieb John Johansen:
> ...
>> atm I think I am in favor of wrapping it in the conditional and
>> defaulting that conditional to false.
>>
>> The ubuntu patch then changing the conditional to true. This way
>> the information is being carried upstream. And only the distro
>> specific tweak is out of tree.
>
> That sounds like a good idea, but... -
>
>
> If you look at utils/test/test-parser-simple-tests.py, you'll notice
>
> # testcases with various unexpected failures
> syntax_failure = [
> ...
> # Syntax Errors caused by boolean conditions (parse_profile_data()
> # gets confused by the closing '}')
>
> followed by a list of all files in parser/tst/simple_tests/conditional/ -
> except those with EXRESULT FAIL because at least those fail correctly
> ;-) (actually they fail for a different reason, but hey, they fail ;-)
>
> So if you add any boolean condition, expect aa-logprof etc. to break
> completely :-/
>
> I'm aware of this since I wrote the test that checks against
> simple_tests, but it has low priority because nobody seems to use
> conditionals in practise. At least I never received a bugreport ;-)
>
> Unfortunately fixing this isn't easy - the tools will probably need to
> handle a "stack" of parenthesis ("I'm inside 'if $foo'") or something
> like that. (Besides conditionals, that stack should also handle
> owner { } and audit { } blocks, and also nested child profiles.)
>
> To make things even worse, this major code change will probably have to
> happen in an area of aa.py which is hard to cover with unit tests.
>
well we are going to have to start fixing this, our plans for policy
versioning and "support" of new features on old parsers rely on boolean
conditional support
>
> For now, a possible workaround could be to abuse variables. The upstream
> code could have something like
> @{RESOLVED_DBUS_SOCKET}=""
> and Ubuntu could set it to the real dbus socket. I know this is ugly
> (and it also means not to use abstractions/dbus-strict), but it's still
> better than breaking all aa-* tools.
>
I'd rather not do this
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20161013/2d9fd2fa/attachment.pgp>
More information about the AppArmor
mailing list