Date: Mon, 3 Sep 2001 11:05:48 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: marius strobl <marius@alchemy.franken.de> Cc: freebsd-stable@freebsd.org, trustedbsd-discuss@TrustedBSD.org, jedgar@fxp.org Subject: Re: samba acl support under 4-stable Message-ID: <Pine.NEB.3.96L.1010903104551.41748B-100000@fledge.watson.org> In-Reply-To: <20010903145052.A30015@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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@fledge.watson.org NAI Labs, Safeport Network Services
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010903104551.41748B-100000>