From: Andreas Gruenbacher (ag@bestbits.at)
Date: 07/23/02-02:43:55 PM Z
Date: Tue, 23 Jul 2002 21:43:55 +0200 (CEST)
From: Andreas Gruenbacher <ag@bestbits.at>
Subject: Re: POSIX ACL MASK
Message-ID: <Pine.LNX.4.33.0207231958310.25902-100000@muriel.parsec.at>
Hello,
this is some explanation of the issues surrounding the POSIX ACL_MASK
entry, and my opinion on it.
POSIX 1003.1e draft 17 document in section B.23 (pages 249 ff.) gives some
of the rationale behind the design chosen. Here is an overview. From draft
17, literally:
[The] ACL entry of tag type ACL_MASK denotes the maximum discretionary
access rights that can be granted to a process in the file group class.
[...]
This standard extends the file group class, as defined in POSIX.1, to
include processes which are not in the file owner class and which match
ACL entries with the tag types ACL_GROUP, ACL_GROUP_OBJ, ACL_USER, or
any implementation-defined tag types that are not in the file owner
class.
In other words, in an implementation with no ACL entries of implementation
defined types, the ACL_MASK entry defines an upper limit of the
permissions granted by any ACL_USER, ACL_GROUP_OBJ, and ACL_GROUP entries,
while it has no effect on the ACL_USER_OBJ or ACL_OTHER entries. The
effective permissions defined by an ACL entry are those permissions which
are present in both the entry and the ACL_MASK entry.
An ACL that has any ACL_USER or ACL_GROUP entries must always also have an
ACL_MASK entry. An ACL that has no ACL_USER or ACL_GROUP entries may have
an ACL_MASK entry, but does not need one.
So the simplest valid ACL consists of three entries (ACL_USER_OBJ,
ACL_GROUP_OBJ, ACL_OTHER). If an ACL has four entries, then these entries
must be of types ACL_USER_OBJ, ACL_GROUP_OBJ, ACL_MASK, and ACL_OTHER (one
each). And then there may be any number of ACL_USER or ACL_GROUP entries
in addition to those four.
A mapping is defined between the file mode permission bits and ACL
entries. The file mode permission bits are those bits displayed by `ls -l'
as rwxrwxrwx, and those are the bits that are also affected by chmod, s
usual. This mapping is not as straight forward as one might expect, and
depends on whether an ACL has an ACL_MASK entry or not:
If an ACL has just the three base entries ACL_USER_OBJ, ACL_GROUP_OBJ
AND ACL_OTHER, then these entries map one-to-one to the owner, group and
other permission bits. If an ACL has an ACL_MASK entry, then the file
group permission bits map to the ACL_MASK entry. Changing the file
permission bits (with chmod) also affects the corresponding ACL entries,
and vice versa.
Here is a snipped from the acl(5) manual page showing this relationship
graphically.
FILE MODE PERMISSION BITS TO ACL ENTRY MAPPING
user group other
----+-------+-------+-------+
| r w x | r w x | r w x |
----+-------+-------+-------+
^ ^ ^
| | +-- maps to ACL_OTHER
| +-- maps to ACL_GROUP_OBJ or ACL_MASK
+-- maps to ACL_USER_OBJ
For the basic case of three ACL entries this means that the behavior on a
system without ACLs is the same as the behavior on a system with ACLs. For
ACLs with more than three ACL entries this mapping plus the ACL_MASK entry
causes the traditional file mode permission bits to always define an upper
bound on the permissions defined by any ACL entries. (This holds true for
systems with no permissions other than rwx in ACL entries at least).
In addition the usual behavior of stat/chmod command sequences is
preserved:
/* Example A */
stat("file", &st); /* remember file mode permission bits */
chmod("file", 0600); /* restrict (or relax...) */
/* do something */
chmod("file", st.st_mode); /* back to state before */
/* Example B */
fd = open("file", O_WRONLY, 0); /* only I may access */
/* do something */
fchmod(f, 0640); /* relax permissions */
In the eyes of the 1003.1e working group that was unfortunately dissolved
some time ago before reaching consensus, this is the least disturbing
design that is able to preserve the behavior (and security!) of legacy
applications, thus providing the most compatibility with legacy POSIX
systems.
Some alternative designs are discussed in draft 17; it is also shown where
these designs fall short.
For NFSv4 I can imagine two different approaches:
(a) Add support for the ACL_MASK entry, e.g., by introducing a pseudo user
identity `POSIX_ACL_MASK@'. This would allow POSIX 1003.1e draft 17
ACLs to be accurately represented by NFSv4 ACLs.
(b) Use the mechanisms defined by NFSv4 to somehow emulate the ACL_MASK
entry, as well as possible.
NFSv4 tries to define a complete, separate semantic model of ACLs. POSIX
ACLs define their own, different semantics.
IMO approach (a) would be most straight forward from the point of view
of POSIX ACLs. OTOH the semantic model of NFSv4 ACLs would have to be
extended to also cover the ACL_MASK entry; simply adding these entries
won't be enough.
Approach (b) won't result in a perfect mapping between the two ACL
systems, especially since the semantic models are surprisingly different.
I have previously been forwarded a proposal for implementing such a
mapping from Marius Aamodt Eriksen <marius@umich.edu>; it is archived at
<http://acl.bestbits.at/misc/NFSv4-acl-mapping.mail> for your reference. I
believe this approach is doable but still too complicated to be practical.
Especially modifying the resulting NFSv4 ACLs would be terrible.
Again, so they are not overlooked, here are some of the mapping problems:
- POSIX ACLs have no DENY ACE's, they always only grant permissions.
- NFSv4 ACE entry order matters, while POSIX ACL entry order does not.
- NFSv4 entry permissions are cumulative; POSIX ACL permissions are
not.
Personally I believe NFSv4's approach of prescribing a semantic model is
flawed, but there isn't much we can do about it after the fact. I really
don't see how either of the above approaches would lead to satisfactory
results.
Regards,
Andreas.
------------------------------------------------------------------------
Andreas Gruenbacher, a.gruenbacher@computer.org
Contact information: http://www.bestbits.at/~ag/
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:05 AM Z CST