On Mon, Jul 31, 2017 at 09:52:13PM +0200, Christian Boltz wrote: > > Why is this one UID handled magically? > > My *guess* is that it is actually -1, but either libapparmor or the > python bindings handle it as unsigned 64bit integer - and > 2^64 -1 == 18446744073709551615 > > I don't say this is perfect (it's probably a bug), but until someone > fixes libapparmor or the python bindings, we'll have to live with this > number. And even after fixing libapparmor, we should probably carry it > for a while to be compatible with older libapparmor versions. > (After making it a signed int, we need to check for -1.)
The Standard actually isn't clear if uid_t is signed or unsigned. I've never seen references to negative user or group so I've always assumed everyone else assumed unsigned. :) > With the test_multi/*.profile adjusted in the second patch: yes :-) I figured :) > The most important "trick" was to set ev['fsuid'] and ev['ouid'] only if > they are != -1 (or 2^64 -1, see above). Without this condition, I'd have > to change the logparser results in several test-*.py files instead of > only in test-logparser.py. Do the tests hard-code -1 in some way? Maybe we should address that too... > > Oh, BTW - as you already guessed, the superfluous trailing whitespace in > the second patch is caused by Konsole and/or KMail. Good good :) Thanks
signature.asc
Description: PGP signature
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
