File System ACLs: Where to go from here in FreeBSD?

[David Collier-Brown]

   I don't know Sun's intentions, but I'll raise the question
and see if anyone comments.

   However, I strongly suspect the Samba team will come down
on the side of NT-compatible ACLS, as they are a genuine
center of expertise at mapping NT and Posix ACLS and
are definitely on the side of more expressive ACLs.

   I'll forward your note to them.

--dave

Robert Watson wrote:
>
> 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 at trustedbsd.org
> with "unsubscribe trustedbsd-discuss" in the body of the message
>

-- 
David Collier-Brown,      | Always do right. This will gratify
Sun Microsystems, Toronto | some people and astonish the rest
davecb at canada.sun.com     |                      -- Mark Twain
(416) 263-5733 (x65733)   |
To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message