This is a technical follow-up to the MR 1863 [1] which attempts to
correct a recently discovered issue between the parser and the kernel
with regards to handling conditional user/other (aka owner) rules.
I've separately posted the kernel patch which adds missing
initialization to the accept2 table in the case one is not provided in
the file pdb.
When looking at the parser, I had to make two modifications:
1) In libapparmor_re I would allocate accept2 when permission index was
used. I would then set the owner bit in each state/index of accept2.
2) In the parser proper I would emit the permsv field, just after the
perms structure with the perms array. The value of the field was set to
3. This I did not initially expect and it took me a moment to see why
the kernel was rejecting my policy.
The kernel only loads accept2 (as u32 values) if the optional permsv
field is present and the value is larger than 2. I feel I'm stepping
over some future-proofing design I'm not aware of.
My main question is: is the issue 570 [2] something that can be fixed in
the parser for the benefit of all past and future kernels regardless of
my earlier-posted kernel patch [3] or is it something that would, for
proper design and not doing the wrong short-term fix, require a
coordinated patch on both sides?
Best regards
ZK
[1] https://gitlab.com/apparmor/apparmor/-/merge_requests/1863
[2] https://gitlab.com/apparmor/apparmor/-/issues/570
[3] https://lists.ubuntu.com/archives/apparmor/2025-November/013873.html
