From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031007 Description of problem: When I apply an ACL with the following permissions the permissions allowing access takes precedence over the ones denying access. setfacl -m g:group1:rwx /mnt/share/Projects setfacl -m g:group2:000 /mnt/share/Projects For example I have a user who is in both group1 and group2 and he will be allowed to access the share instead of being denyed access. The reason I am submitting this as a bug is because it would be more affective if it denyed before it allowed access. This is also the standard behavior behind windows ACL structure which is were I am running into the problem. I am currently transitioning from a windows file server and what I am trying to do is allow Domain Users access to that folder while denying access to all users in group 2. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. add group1 and add group 2 2. assign a user to both groups 3. apply permissions to share: setfacl -m g:group1:rwx /mnt/share/Projects setfacl -m g:group2:000 /mnt/share/Projects 4. Access the share and the user will be allowed access. Actual Results: User is allowed access Expected Results: User should be denied access Additional info:
This is not a bug --- the behaviour is specified in the POSIX.1e withdrawn draft standard, the standard on which POSIX ACLs are based. Linux is simply following the accepted POSIX behaviour here. See section 23.1.5 on pages 42 and 43 of the spec at http://wt.xpilot.org/publications/posix.1e/download.html for details of the requried POSIX behaviour. In particular, lines 194--201 specifically require that we match the process against a granting group ACL on a file in preference to a denying one. That POSIX semantics are not the same as Windows semantics is not a bug!