Bug 113028 - ACL deny before allow
Summary: ACL deny before allow
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
(Show other bugs)
Version: 3.0
Hardware: i686 Linux
Target Milestone: ---
Assignee: Stephen Tweedie
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2004-01-07 16:27 UTC by Andrew Hydle
Modified: 2007-11-30 22:07 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-03-30 13:48:03 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Andrew Hydle 2004-01-07 16:27:34 UTC
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:

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:

Comment 2 Stephen Tweedie 2004-03-30 13:48:03 UTC
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!

Note You need to log in before you can comment on or make changes to this bug.