[apparmor] [patch] [1/2] support 'owner' file events in logparser.py

Seth Arnold seth.arnold at canonical.com
Mon Jul 31 20:22:10 UTC 2017


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20170731/e3bd95d9/attachment.pgp>


More information about the AppArmor mailing list