Inheritance in grsecurity2
Posted: Sun Jul 27, 2003 1:04 pm
Hi
After getting learning acl's to work properly with grsecurity2, I finally managed to have a learnt acl that seems fairly decent.
however, i'm a bit confused about some things...
I, of course, have a default acl that allows some amount of things.
Then I have a users acl that allows a bit more.
However, I'm a bit confused about how that works...my user is in users, if I (with a program not explicitly allowed or denied) try to access some files not explicitly allowed by the / subject acl of role users but explicitly allowed by the default acl, will I get access to them then or not?
So I guess the real question is: Is there role inheritance, or is the matching limited to only the first match?
I.e. if something doesn't match in user acl (i.e. neither allowed, nor denied, will group acl be tested, and will default acl then be tested?
It makes quite a big difference wrt. duplicate entries and such (And I'm not fond of trying enabling the acl without knowing...)
Regards,
Jens Andersen
After getting learning acl's to work properly with grsecurity2, I finally managed to have a learnt acl that seems fairly decent.
however, i'm a bit confused about some things...
I, of course, have a default acl that allows some amount of things.
Then I have a users acl that allows a bit more.
However, I'm a bit confused about how that works...my user is in users, if I (with a program not explicitly allowed or denied) try to access some files not explicitly allowed by the / subject acl of role users but explicitly allowed by the default acl, will I get access to them then or not?
So I guess the real question is: Is there role inheritance, or is the matching limited to only the first match?
I.e. if something doesn't match in user acl (i.e. neither allowed, nor denied, will group acl be tested, and will default acl then be tested?
It makes quite a big difference wrt. duplicate entries and such (And I'm not fond of trying enabling the acl without knowing...)
Regards,
Jens Andersen