samba acl support under 4-stable

[Robert Watson]

On Mon, 3 Sep 2001, marius strobl wrote:

> as 5.0-release is delayed for a year and i don't want to run -current on
> a production server, how are chances that the neccessary bits for samba
> acl support are merged into 4-stable ? 
> 
> is there already a patch for 4-stable available ? 
> 
> i guess it's not only me waiting for this feature

Currently, there are no plans to backport the EA and ACL support to
FreeBSD RELENG_4.  However, in light of the release schedule changes, it
would probably be worth discussing what would be involved in a backport.
There are a number of issues that would need to be considered:

(1) Actual cost of the backport in man-hours, including all dependencies.
(2) Consideration of current stability and completeness of the code.
(3) On-going debate in some of the other communities working with ACLs as
    to what the interfaces should look like.

(1) requires that the ACL kernel code, libraries, utilities, and
    application patches be backported.  This is a non-trivial effort, I
    would estimate at least 2-3 weeks of work given divergence and testing
    requirements. 

    In the form of dependencies, you also pick up the requirements that
    EAs be backported, which similarly have kernel, library, and utility
    components, with non-trivial efforts involved.  I'd throw in at least
    another week or two here. 

(2) We had relied on having a "unstable" 5.0-RELEASE cycle to allow more
    broad testing of ACL code before it hit mainstream.  Right now,
    deployed use of the FreeBSD ACL code is pretty low, and moving the
    code to the RELENG_4 branch would represent a much more firm
    commitment on our part that it worked.  Not, mind you, that I think it
    doesn't work, just that normally I would require a higher level of
    confidence in the form of broad testing before doing such a backport.

    There are some components of the work that are not yet complete --
    many userland applications that should know about ACLs don't.  You see
    this in the form of, for example, text editors which re-create the
    file when they edit it, and fail to preserve ACLs, or in our inability
    to backup ACLs using dump (although extensions to tar are now
    available to deal with EAs).  Lack of broad testing of interactions
    between ACLs and applications as an important thing to remedy before
    we can proceed.

(3) This morning I got e-mail from the Linux side of the world laying out
    plans to utterly transform their previously portable ACL interface.
    This is, in some senses, necessary to support NFSv4, but really
    throughs a wrench into concepts of portability.  We have pretty
    strictly implemented the POSIX.1e ACL syntax and semantics, in line
    with IRIX and other platforms, and supported by Samba.  NFSv4 has zero
    deployment right now, and the interactions between UNIX and NFSv4 ACLs
    are pretty well undefined.  As long as ACLs live only on the -CURRENT
    branch, we can adapt to that kind of thing fairly freely--once we push
    them onto a -STABLE branch, the APIs are frozen.

So there's a lot involved in such a backport--if we do go ahead with it,
we'll need firm commitments of time (substantial chunks of time, no less)
for development, testing, and application adaptation.

Given these issues, my initial response would be "we'd love to, but
resources simply aren't available".  On the other hand, I would certainly
not block any effort to backport, as long as it addressed the above
concerns, and would certainly want to be involved.  My recommendation for
anyone wanting to do a backport would be that they get involved in making
sure the 5.0-CURRENT implementation is really solid.  In particular, this
means:

- Work to make sure the EA implementation is bug-free and resistant to
  failure.  This will require a lot more testing than it has currently
  had, especially in high-load environments.  It probably also requires
  additional investment in understanding the behavior under failure of the
  system, especially WRT partial writes during a crash, etc.  Also,
  investment in understanding potential performance bottlenecks in the
  code, such as excessively broad locking, and ways that could be
  improved.

- Work to make the ACL implementation less resistant to failure -- in
  particular, in crash situations.

- Testing of applications when ACLs are enabled to see what "weird" things
  happen--particular WRT preservation of ACLs when applications act on
  files (including WRT copying and moving files), and whether applications
  act properly and respect ACLs.  One example of this comes via the
  eaccess() system call I'm about to introduce on -CURRENT, which allows
  an application to ask if it has the rights to open a file without
  actually opening it (to be distinguished from access() in that it uses
  effective not real credentials).  This allows applications such as file
  browsers to correctly display the writability of files in the user
  interface.  This call is actually being introduced to support the Finder
  on Mac OS X, but would also be useful for KDE and related software.

Discussion of this stuff should probably move to the trustedbsd-discuss
list, although feedback from the freebsd-stable list would be solicited if
any forward progress requiring review were to be made.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
robert at fledge.watson.org      NAI Labs, Safeport Network Services


To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message