The FreeBSD ACL implementation is currently based on a late POSIX.1e
draft, and is similar in functionality to the ACL support in Solaris,
IRIX, and Linux. It was developed along a similar timeline to the Linux
ACL support, and Andreas and I chatted a fair amount along the way so the
parallels are strong -- in fact, the Samba ACL support is almost
identical, and the ACL API man pages on Linux are directly derived from
our ACL man pages (and maybe some of the code?). Differences lie
primarily in three areas:
(1) We follow the POSIX.1e specification for file creation modes, in which
the ACL and umask are combined with the cmode to generate a
conservative ACL. This was the same as IRIX, but different from
Solaris; Linux adopted the Solaris model. Since then, IRIX has (I
believe) also switched to the Solaris model. Our model is
"conservative" in that it will never offer broader rights on a
file
than the umask permits, but it turns out to be quite useful in some
environments to allow the ACL on a directory to overide the umask of a
program writing files there.
(2) We offer a few fewer support routines in user space, such as routines
to copy an ACL from one file to another. This has been getting
gradually fleshed out over time.
(3) We don't offer Solaris-compatible NFSv3 extensions to allow remote
management of ACLs via NFS, although the ACLs are enforced on the
server so they are "implemented". I'm not sure if these
patches were
merged to Linux or not, but they were floating around for quite a
while.
As I see it, there are two directions we can take file system ACL support,
and here-in lies the Big Question:
(a) We can continue down the POSIX.1e branch of the ACL world, continuing
to enhance and refine our support. For example, continuing to flesh
out a few missing spots in user space, move over to the now
predominent model for generating new file permissions
(non-conservative ACL override), implement NFSv3 RPCs. This is some,
work, but not a huge amount of work.
Or, the a new option that has basically become feasible over the last six
years since the POSIX.1e direction was the one we selected:
(b) We can consider a migration to NT/NFSv4-style ACLs, which is the route
that Darwin has taken. They use the FreeBSD user space ACL library
and POSIX.1e interfaces, but use ACLs with more NT-like semantics.
In particular, they have notions of taking ownership, slightly finer
grained directory controls, etc. This is a lot of work.
Option (b) is an interesting new choice as compared to 1999, when NTFS
ACLs were in the distinct minority in terms of the syntax and semantics
they offered. However, they become much more appealing if we consider
that there appears to be a much clearer mapping from NTFS ACLs to NFSv4
ACLs than there is from POSIX.1e ACLs to NFSv4 ACLs. And the fact that
Mike Smith at Apple has taken the time to make it sit behind our library
for the Darwin implementation on HFS+, etc, is also quite interesting.
When I implemented the library, it was my hope that it would support that
sort of thing, but we never actually tried :-).
If we don't start considering a move to Darwin/NTFS ACLs, then we run into
a problem when it comes to implementing NFSv4 ACLs: the mapping and
behavior is rather poor and unclear. There's an ID on the topic, which I
basically read as saying "This is all rather hard and rather
non-ideal".
Apple has identified that, for them, compatibility with NT (and possibly
NFSv4?) is the way to go, and they may be right. On the other hand, the
result is much reduced possibility of clean interoperability with Linux,
Solaris, IRIX, and so on. So there's a definite trade-off.
If we do make this change, I'd like to also simultaneously consider a
change to add an array size field in the ACL structure -- right now, we
have a fixed maximum size, and there's a field that says how much of that
space is used, but not how much space is available. If we want to support
longer ACLs in the future, having a variable array size will improve
efficiency and add flexibility.
If we want to consider switching to the Darwin ACL model, it sounds like
the strategy would be something like the following:
(1) Investigate the model closely, and compare it to NTFS. Identify
whether any of the significant semantic differences is a problem.
(2) Investigate the NFSv4 model closely, and decide if there is a clean
and useful mapping or not. If there are nits, approach Apple and
decide whether the nits are necessary or not.
(3) Produce an implementation on top of UFS2 to experiment with, and see
what happens. Specifically, how our current in-kernel APIs and data
structures work with it.
(4) See whether there is a sensible mapping from existing POSIX.1e ACLs to
the newer ACL style, which could be performed at run-time when reading
an existing ACL-enabled partition. Specifically, in the long term
will we need to support two ACL modes -- a legacy POSIX.1e mode and a
new Darwin/NTFS/NFSv4 mode, or can we run entirely in the new mode and
run-time translate old ACLs to support a migration path?
(6) Investigate what the implications are for applications, especially
relating to supporting two ACL models. Will applications get stuck
figuring out how they co-exist, or can the kernel help to hide it?
(7) Investigate what the implications are for users, who may find that the
semantic changes are significant -- and disruptive, potentially.
Apple has chosen to provide separate tools for managing ACLs, rather
than the POSIX.2e ones, and we might find the same is necessary.
It would be interesting to know if systems other than Darwin have started
exploring this route. For example, Sun has always been quite interested
in NFSv4 -- are they considering or have they made an ACL change that
corresponds with the integration of NFSv4 support?
My feeling is that NFSv4 might be the compelling argument to consider a
migration, and that if we are going to migrate, the sooner we get started
with the implementation work, the better. Any thoughts here are welcome.
Robert N M Watson
To Unsubscribe: send mail to majordomo@trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message
Long message, excuse the butcher job. On Sat, September 17, 2005 08:19, Robert Watson wrote:>(b) We can consider a migration to NT/NFSv4-style ACLs, which is the route > that Darwin has taken. They use the FreeBSD user space ACL library > and POSIX.1e interfaces, but use ACLs with more NT-like semantics. > In particular, they have notions of taking ownership, slightly finer > grained directory controls, etc. This is a lot of work. >Option (b) is an interesting new choice as compared to 1999, when NTFS >ACLs were in the distinct minority in terms of the syntax and semantics >they offered. However, they become much more appealing if we consider >that there appears to be a much clearer mapping from NTFS ACLs to NFSv4 >ACLs than there is from POSIX.1e ACLs to NFSv4 ACLs. And the fact that >Mike Smith at Apple has taken the time to make it sit behind our library >for the Darwin implementation on HFS+, etc, is also quite interesting. >When I implemented the library, it was my hope that it would support that >sort of thing, but we never actually tried :-). >If we don't start considering a move to Darwin/NTFS ACLs, then we run into >a problem when it comes to implementing NFSv4 ACLs: the mapping and >behavior is rather poor and unclear.From a personal standpoint, going the Darwin/NFSv4/NTFS path is more desirable to me simply because most of the networks I work on are BSD+NT networks. Since I have no Solaris, Linux, or OSX boxes on them and don't use NFS, I'm happy as long as SMB support continues to get better, so either way isn't of a great deal of concern to me. My question is, given that mapping NFSv4 onto the existing POSIX structure is possibly ambiguous, is the reverse also true? With NTFS giving finer grained control, and the implication in your writing that mapping NFSv4 onto Darwin/NTFS is trivial in comparison, is it possible to make the native mode Darwin/NTFS compatible and then map the POSIX side onto that? My very informal investigation of POSIX.1e leads me to believe that implementation on a system with NTFS style ACLs and features would be trivial compared to the reverse; Adding POSIX.1e to NT for example strikes me as fairly easy. It's also of passing interest that POSIX.1e never became a "true" POSIX standard, is incomplete, and has been abandoned by IEEE; Down that road lies even more cross-platform interoperability and compatibility problems I would imagine, if parts of the draft are open to interpretation.
[ ...I guess freebsd-security is the mailing list other replies (Allen) are using... ] Hi, Robert-- This big an email may have frightened away the usual suspects, or perhaps the discussion about bumping library version numbers is stealing too much attention. :-) Nevertheless, I'll toss a few comments into the ring... On Sep 17, 2005, at 8:19 AM, Robert Watson wrote:> (1) We follow the POSIX.1e specification for file creation modes, > in which > the ACL and umask are combined with the cmode to generate a > conservative ACL. This was the same as IRIX, but different from > Solaris; Linux adopted the Solaris model. Since then, IRIX has (I > believe) also switched to the Solaris model. Our model is > "conservative" in that it will never offer broader rights on a > file > than the umask permits, but it turns out to be quite useful in > some > environments to allow the ACL on a directory to overide the > umask of a > program writing files there.The first system I saw ACLs on was AFS, which used ACLs to extend and override the Unix mode bits in a more specific fashion. I believe this is what you refer to as the "Solaris model", but let me try to be more specific: Given a file "foo", with 664 (rw-rw-r--) permissions, you could add a user-specific positive permission (user "adam" can write to the file), and this would apply even if adam was not a member of the group associated with the file. Likewise, you could add a negative permission, such as "no access" for "betty", which would mean betty could not read/write/list/etc the file, even if betty was a member of the group which owns the file "foo". Likewise, you could set up ACLs for groups, where a specific ACL would extend and override the Unix mode bits. If foo was group-owned by staff, you could define a negative ACL for "students" like "no write", and people who were in the students group would not have write access, even if those users were also part of the staff group. [ This was actually a pretty common case, as grad students were employed as TA's or as junior sysadmins keeping the computing clusters going. ] Evaluation order was apply the Unix mode bits as appropriate considering the uid/gid of the process/user accessing the resource, then apply group-based rules, then apply per-user rules, to end up with the final set of access rights.> Option (b) is an interesting new choice as compared to 1999, when > NTFS ACLs were in the distinct minority in terms of the syntax and > semantics they offered. However, they become much more appealing > if we consider that there appears to be a much clearer mapping from > NTFS ACLs to NFSv4 ACLs than there is from POSIX.1e ACLs to NFSv4 > ACLs. And the fact that Mike Smith at Apple has taken the time to > make it sit behind our library for the Darwin implementation on HFS > +, etc, is also quite interesting. When I implemented the library, > it was my hope that it would support that sort of thing, but we > never actually tried :-).I remember Mike from the Darwin lists, he's a good guy (IIRC), and Apple has felt a strong need to implement filesystem and network sharing semantics which work well with Windows/NTFS/CIFS and with Samba. While many people using FreeBSD have less need for such interoperability, it wouldn't hurt to do better, especially if FreeBSD can take advantage of the work already put into Darwin.> If we don't start considering a move to Darwin/NTFS ACLs, then we > run into a problem when it comes to implementing NFSv4 ACLs: the > mapping and behavior is rather poor and unclear. There's an ID on > the topic, which I basically read as saying "This is all rather > hard and rather non-ideal". Apple has identified that, for them, > compatibility with NT (and possibly NFSv4?) is the way to go, and > they may be right.NFS filesharing is much less important to Apple, frankly, and I would not expect them to be taking the lead on NFSv4. I'm not even sure NFSv4 is really on their radar map at all compared to providing an integration of Samba, OpenLDAP, Kerberos with decent GUI management tools in order to provide a reasonable replacement for a Windows domain controller or ADC.> On the other hand, the result is much reduced possibility of clean > interoperability with Linux, Solaris, IRIX, and so on. So there's > a definite trade-off.This concern probably matters more to FreeBSD than to MacOS X. The interoperability issues with ACLs are minor compared with issues such as UFS being case-sensitive, whereas NTFS, CIFS/SMB, and HFS+ all being case-insensitive (but perhaps case-preserving). There's also the issue of Unicode support in filesystem pathnames, which provides a significant advantage to HFS+ for "normal people" [1] using anything outside of ASCII or ISO-8859-1. -- -Chuck [1]: Read this as somebody's grandmother from Russia or China or whatever that wants to name files in her native language. :-)