Date: Fri, 22 Oct 1999 10:25:52 -0400 (EDT) From: Robert Watson <robert@cyrus.watson.org> To: freebsd-arch@freebsd.org, freebsd-security@freebsd.org Subject: VFS, vnodes, and ACLs: Thoughts and Questions on integrating , POSIX.1e ACLs into FreeBSD Message-ID: <Pine.BSF.3.96.991022100119.52532D-100000@fledge.watson.org>
next in thread | raw e-mail | index | archive | help
I'm in the process of reviewing the POSIX.1e draft to being implementing
ACLs. As you're probably aware, all other major UNIX distributions have
extended ACL support available, if not turned on in the default file
system. For those that have been following the POSIX.1e list recently,
I've posted a summary of some of the ways they get them into the FS (IRIX:
has general purpose attribute support; Solaris: an extra inode and file
structure for each ACL; Linux: an extra block pointer in the inode) -- and
now I have some questions about adding this support to FreeBSD.
The first question has to do with integration into the vnode as vnops.
The closest current vnops are vop_getattr and vop_setattr -- getting and
setting standard file attributes (mode, size, modification dates, et al).
It makes sense conceptually that the ACLs might be included in this
attribute information, as a substructure or pointer or the like. However,
because ACL support across different file systems is nebulous and likely
to be inconsistent for a long time (if not forever), it makes sense to
think of getting and setting ACLs as vnops themselves -- for this purpose
on an experimental kernel I have introduced vop_getacl and vop_setacl.
This allows the ACLs to be exposed in their own right to the layering and
file system behavior -- file systems that don't implement ACLs or don't
know about them return EOPNOSUPP, and a layered file system could easily
choose to intecept ACL changes explicitely and implement tham in a union
or the like.
If the vnode interface is aware of ACLs, this raises the format and
semantics of ACL structures exposed in vnops, as they should/must be
consistently interpreted and implemented. My temptation is to make
POSIX.1e ACLs part of the vnode-aware types -- the interface seems to be
standard across the various UNIX implementations, and in this sense it's
similar to the mode, uid, gid values in vattr that we also expose
non-opaquely. For reference, here's a simplified view of how most
platforms have chosen to represent ACLs for their kernel syscall
interface:
They either define an acl_t structure referring to an array of ACL entries
(acl_entry_t), or they directly pass around arrays of acl_entry_t's via
syscalls. For example, the LINUX (and Solaris) ACL syscalls look like
this:
int acl(const char *pathp, int cmd, int aclcnt,
acl_entry_t *aclentp);
int facl(int filedes, int cmd, int aclcnt,
acl_entry_t *aclentp);
typedef struct acl_entry_t {
int a_type;
uid_t a_id;
mode_t a_perm;
} acl_entry_t;
The various POSIX.1e interfaces refer instead to acl_t's which are
presumed to store references to acl_entry_t's, so you could also imagine a
syscall interface referring to an acl_t structure, and without the count
variable.
typedef struct acl_t {
int entries;
int size;
acl_entry_t *entp;
} acl_t;
This provides a general ACL structure with a pointer to an array of
acl_entry_t's, or individual "this user/group gets this right". The other
approach to doing this might be the approach of:
typedef struct acl_t {
int entries;
int size;
acl_entry_t ent[3];
};
/* 3 is the minimum entries in an ACL */
This is where the aclcnt argument could come into play. Which would
remove indirection in the vnode-aware structure and therefore perhaps be
"nicer". Either way, it looks like acl_t's would be the best type (in
whatever form) to pass ACLs around in the kernel with, as they can contain
data describing the array of acl_entry_t's, and not just the entries as a
direct array would do.
This vnode approach then moves the responsibility for implementing ACLs to
individual file systems -- a layer could choose to take advantage of some
existing mechanism (extrended attributes) to store them.
There's also the issue of evaluation -- right now, my understanding is
that the vnode call vop_open is implemented by each file system, which may
return EPERM if it desires. POSIX.1e describes an evaluation procedure
for ACLs -- preusmably providing a set of common functions all file
systems (optionally) can use for ACL evaluation makes sense -- this would
mean (for example) that the same ACL evaluation routines could be used in
FFS and MFS without replicating code all over the place.
The other option is to treat ACLs as opaque and fs-specific, but that
makes layering a lot less useful for implementing ACLs. On the other
hand, it would also force us to follow the POSIX.1e model for ACLs, which
while popular might benefit from improvement?
Anyhow, thoughts on the topic would be much appreciated. I have not yet
tried to address the issue of integrating ACL storage into various file
systems. A first bet might be NFS as (apparently) there are NFS
extensions for passing ACLs from ACL-aware servers (such as Solaris, IRIX,
and presumably Linux sometime soon as they're talking about it on their
acl-develop mailing list). Another choice might be Coda/AFS which both
support ACLs, albeit not POSIX.1e-style ACLs. Some conversion between the
two could be done for the purposes of inspecting ACLs, although I think
not setting (AFS groups work quite a bit differently than POSIX-style
groups, as they allow users to create them on the fly and modify them as
they see fit).
Robert N M Watson
robert@fledge.watson.org http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.991022100119.52532D-100000>