Bug 5760 - acl misbehaviour, when acl mask is set and map system is turned on
Summary: acl misbehaviour, when acl mask is set and map system is turned on
Status: NEW
Alias: None
Product: Samba 3.2
Classification: Unclassified
Component: File services (show other bugs)
Version: 3.2.2
Hardware: x86 Linux
: P3 normal
Target Milestone: ---
Assignee: Jeremy Allison
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-09-15 03:24 UTC by Michal Soltys
Modified: 2009-08-06 09:13 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michal Soltys 2008-09-15 03:24:34 UTC
Under the following scenario:

- map system = yes
- create mask set appropriately (not blocking x bit on group, e.g. 777 for sake of testing)
- extended acls are set on file, including acl mask

It will be impossible to clear system flag - samba will:

- clear only group's x bit, when unsetting system flag
- will set it for both mask and group, when setting system flag
- will report whenever it's set or not basing on mask's x bit only

for example, following file will report mask as set:

user::rw-
group::rw- or rwx
mask::rwx
other::rw-

as unset:

user::rw-
group::rw- or rwx
mask::rw-
other::rw-

In the former case, unsetting system flag will clear only group's flag, and samba will continue considering the file as a system one. The only way to clear system flag status seems to be through setfacl.

Basing the decision on group's x bit only - in case of presence of extended acls - seems like a good fix, as mask shouldn't be carelessly changed (it sets upper bound of permission for all named users/groups and unnamed owning group - so it could have an adverse effect on e.g. directories for named groups).
Comment 1 Michal Soltys 2009-06-26 06:20:41 UTC
Short update - I've tested the above with samba 3.3.5 - the behaviour is the same. More detailed description follows (OG - owning group, MK - mask):


1) when determining system flag

OG's X bit setting doesn't matter, only MK's X bit determine the status of system flag.

2) when unsetting system flag, following modifications happen:

OG:RWX -> RW
MK:RW  -> RWX

OG:RWX -> RW
MK:RWX -> no change

OG:RW     -> no change
MK:RW/RWX -> no change

It looks like OG's X bit is used to determine whenever to alter bits or not.
If yes - OG's X is set to emulate system flag, and MK's X is always set

3) when setting system flag, following modifications happen:

OG:RW  -> RWX
MK:RW  -> RWX

OG:RW  -> RWX
MK:RWX -> no change

OG:RWX -> no change
MK:RW  -> no change

The behaviour seems analogous to #2 - OG's X bit determines if to alter bits or not.
If yes - OG's X is set to emulate system flag, and MK's X is always set

---
Overally - changing #1 behaviour to rely on OG's X bit, instead of MK's would likely suffice.
Comment 2 Guenther Deschner 2009-08-06 09:13:18 UTC
Jeremy, any idea what is going on here ?