On Thu, 8 Mar 2001, David Brownlee wrote:

: > I too think the NetBSD kernel is not the right place to solve this
: > problem.  It may be possible to do it in userland (eg, a userland Samba
: > or WINS server that keeps ACLs in a parallel filesystem tree), but I
: > really don't think it belongs in the kernel.
: >
: 	Another option could be some strange AFS loopback mount - bearing
: 	in mind the requirement that unix users have the same access as
: 	remote SMB users.

Whether it's "possible" isn't really a criterion for whether code should be
in the kernel or userland.

ACL processing of the type desired here belongs in the kernel, not because
of implementation ability, but because ACLs are best represented as an
integral part of filesystem metadata.  ACLs are simply a longer version of
the same information presented by owner, group, and permissions bits in the
current fs layout.

Most ACL implementations for ffs use a cheap flag that indicates presence of
extended ACL information, which would trigger further permissions checks on
an inode access (only when ACL support is available and/or activated for the
mount point).

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  Wasabi NetBSD:  Run with it.
-- NetBSD 1.5 now available on CD-ROM  --  http://www.wasabisystems.com/