[ACL-Devel] FS meta information (properties/attributes/...)
Robert Watson
robert@cyrus.watson.org
Sun, 16 Apr 2000 16:38:24 -0400 (EDT)
On Sun, 16 Apr 2000, Andreas Gruenbacher wrote:
> -- Fixed attribute size: Allocating fixed-length records for file
> attributes (which you are apparently doing) probably leads to very clear
> code. I don't think this is a good thing to do, however. Attributes like
> ACL are inherently dynamic size. It probably is hard to guess maximum
> sizes for other attributes, as well. A variable-size attribute
> implementation would avoid such arbitrary implementation limits.
In most implementations of ACLs that I am aware of, ACLs have a fixed
maximum size, and this is relatively small. This is not the case for the
Linux implementation, but for the FreeBSD implementation we place a bound
of 32 entries. I believe IRIX limits at 16 or 24. In AFS and Coda, a
relatively small hard bound is also used, although I don't have a figure
offhand.
Also, only the maximum size of the attribute is bounded--the attribute
itself can take on the value of undefined, or anywhere between zero and
the maximum size.
For capability labels, we see the structure in question being of fixed
size; similarly, our MAC labels are of fixed size. Optimizing for an a
priori fixed bound made sense for us. However, the API does not prohibit
attributes of unbounded (64 bit) size.
This said, I recognize this is a serious limitation that will no doubt
have to be removed at some point.
> -- Retrieving attributes: Retrieving multiple (all) attributes of a
> file is expensive. For that operation, you have to read all attribute
> files. I assume attribute stores have a pattern of access with high
> locality of reference. Your design maybe defeats efficient caching and
> fast access (access checks will require reading at least ACL and MAC
> labels; backups will require reading all attributes).
Yes -- we see this as a moderate term solution. One problem you've seen
with ACL code, and that we've also seen, is that modifying the base file
system is a (man hours) expensive operation. You lose backwards
compatibility on the fs, have interop problems, etc. While you lose out
on the performance for the short term implementation, you actually get
more working and deployed code at the end of the day.
I see moving towards a disk block based extended attribute mechanism in
the future, but not as a short term development target. I also see
support for the code coming out of the FreeBSD file system community as
opposed to the security community, as that also increases the chances that
the performance and integration will be strong, as well as easier
acceptance in the base operating system.
Not that any of your points are incorrect--I see it more as an issue of
immediate feasibility than a technical argument. Other operating systems
have also taken this route, including Trusted IRIX.
> (Concerning backups: Backing up the attribute files plus the data files
> is useless since you cannot guarantee which inode numbers files will be
> assigned to when they are restored. This is no problem with the disk
> quota files, since UIDs can be assumed constant.)
We see backup tools having to be aware of the attributes an explicitely
back them up, rather than the backup and restore cycle using the attribute
backing files. Presumably it would be important to assure that a backing
file was not used when it shouldn't be. :-) Ways in which this might be
addressed could include generation information from the superblock, et al.
Including the inode generation number would also be a good way to sanity
check that the attribute data is in synch with the file system.
> -- Defining allowed attributes:
> Only root defines attribute names in your implementation. I think a
> file's owner should be able to allocate user attributes (like an MD5
> checksum, to stay with your example).
>
> Only the system itself should be able to allocate system attributes
> (like ACL, Default ACL, Capabilities, etc.) To me it is not clear how
> you support that. I could not find documentation on that.
I currently don't make a distinction between a user and a system attribute
namespace--i.e., there's a single namespace, but particular attributes
have particular permissions for reading and writing. I define the
following possibilities for both reading and writing per-attribute:
kernel
root
owner
anyone
I.e., if the attribute has a write-level of owner, presumably the kernel,
root user, and file owner could modify the attribute. Read access works
in the same manner. These permissions are stored as part of the backing
file header.
In IRIX, does the root user see the user name space, or the system
namespace? As root can own files, presumably the correct distinction is
for the kernel to see one namespace, and all userland processes to see the
others?
Introducing a distinction between the namespaces might make sense,
although given the current setup of attributes by the administrator in
this implementation, would be less immediately useful.
> > I'd love to see cross-platform portability on this interface--POSIX.1e
> > doesn't cover it. You can see a slightly dated version of the code (I
> > will update it shortly) on http://www.trustedbsd.org/downloads/. This is,
> > of course, for a BSD-style UFS/FFS and VFS, but might be useful. Also,
> > the FreeBSD extattr(9), VOP_GETEXTATTR(9), VOP_SETEXTATTR(9) man pages
> > cover the interface semantics in the kernel.
>
> Robert, where can I find these man pages?
I asked around, and apparently FreeBSD man pages for various versions are
available via:
http://www.FreeBSD.org/cgi/man.cgi
You can select the version, and so on. The search is case sensitive for
man page names, so try:
VOP_GETEXTATTR
VOP_SETEXTATTR
extattr
extattrctl
And once I commit getextattr and setextattr, those man pages should also
be there (might have to wait 24 hours for the web site to rebuild to pick
those up).
I hope to have syscall man pages in shortly. Here is the current API from
the FreeBSD syscall master file (from which syscalls and libc functions
are automatically built):
355 STD BSD { int extattrctl(const char *path, int cmd, \
const char *attrname, char *arg); }
356 STD BSD { int extattr_set_file(const char *path, \
const char *attrname, struct iovec *iovp, \
unsigned iovcnt); }
357 STD BSD { int extattr_get_file(const char *path, \
const char *attrname, struct iovec *iovp, \
unsigned iovcnt); }
358 STD BSD { int extattr_delete_file(const char *path, \
const char *attrname); }
> How about binary attribute values? It seems your proposed command line
> utilities choke on them. Shouldn't the user interface allow attributes
> to be passed in/out in an encoded form, such as a hex dump or base64?
I haven't yet commited the actually userland (non-management) utils for
this reason -- I've modified getextattr to dump attributes in a hexdump
style format by default, and use vis() to generate a string form if ``-s''
is passed to getextattr. I'm still thinking about setextattr, and assume
that input to stdin in a hexdump or base64 format would make most sense.
Utilities in the FreeBSD x.x-CURRENT branch are still flexible, so I see
adapting the utilities based on needs that turn up from real-world use.
Presumably it would be nice to be able to do:
getextattr acl_access /var | setextattr -f - acl_access /usr /boot
So that attributes can easily be copied.
> > 3) Space for attributes relating to quotas is billed to the attribute file
> > owner, not the owner of the object the attribute is attached to
>
> It seems that needs fixing.
I think this may depend on the attribute--right now, BSD quotas allow
accounting and limiting based in two categories: inode count, and block
count. If you consider ACL, capability, and MAC label metadata to fit
into the fixed-cost file metadata category, it would make more sense to
simply eat that in the inode count. For user data, it would make more
sense to bill to the quota of the user.
Presumably in a split system/user model, where to bill becomes a lot
easier--system attributes are considered file system overhead, and user
attributes are billed against user data.
> > 4) We can't save space by allowing identical attribute values to consume
> > the same space, which is an optimization quite possible and effective with
> > ACLs. Clearly the backing file design could be modified to handle this
> > through an extra level of indirection (attribute.index, attribute.value)
> > but there are still limitations.
>
> Hardly seems possible with your indexing-by-inode scheme. In my ACL code I'm
> storing pointers to disk blocks in inodes directly.
In the index-by-inode scheme, the primary backing file would become an
array of pointers/lengths into the second file. The attribute data file
would against consist of [attribute header, attribute data], and a
refcount would be introduced in the header. A variety of semantics would
be possible, including inheritence.
> > 6) The current limitation relies on a per-attribute-backing-file lock,
> > which throttles access to attributes. This is relatively easily fixable,
> > as it's a property of our implementation.
>
> I guess that's not a big problem.
In bringing up the current FreeBSD implementation, I have two goals--
1) Suggest a possible avenue for accelerated development and use of
extended attributes, as they don't require changes to the underlying
file system. I implemented FreeBSD extended attributes in a weekend,
which is substantially cheaper in hours than the time it took me to
design and start prototyping modifications to the underlying filestore,
newfs, fsck, etc.
Implementation of capabilities, ACLs, and mandatory access control
have been made possible in a much faster form, and introducing
independence between the implementation of these security extensions
and the filestore was also a bonus.
2) Determine whether or not current utility interfaces and APIs are
sufficient to cover both underlying storage mechanisms. As the APIs
are still largely under development, as are the tools, now is the
time to think about this. I have not yet provided manpages for
the attribute system calls, but will do so shortly.
As I've pointed out, I see long term use of extended attributes on FreeBSD
moving towards storage in the underlying file store, for many of the
reasons you've pointed out:
o Performance (locality, etc)
o Flexibility (no bound on size)
o User introduction of attributes on demand
o Accounting/Quotas
Thanks,
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
-------------------------------------------------------------------------
Linux ACL Developers List --- http://acl.bestbits.at/acl-devel/
To unsubscribe, send a message with `unsubscribe acl-devel'
in the message body to majordomo@bestbits.at.
-------------------------------------------------------------------------