> Files in Linux currently have two components. One is the file data
> itself, accessed through the open/read/write/close interface. The
> other component is the file's many attributes, which are read through
> stat() and written through utime(), chmod(), chown(). The attributes
> are also consulted changed as a side effect of many file operations.
So what, I hear you ask, does XFS do WRT this whole issue?
XFS supports two sets of extended attributes on each file system
object.
Root attributes may be accessed only by processes with appropriate
privilege (CAP_FOWNER || (superuser_enabled && (euid == 0))).
Interfaces such as acl_set_file() allow policies matching chmod().
User attributes may be accessed under the same conditions as data.
Attributes are stored as name/data pairs and are stored using the
same mechanisms as data. Thus, large attribute issues don't arise
until large file issues arise.
In Irix, root attributes are used to store ACLS, capability sets,
sensitivity and integrity labels, and near-line storage information.
There's been talk of using them for audit triggers and checksums,
although that hasn't happened so far. I don't know of anything that
uses user attributes, but as my focus is security that may just mean
I'm not looking hard enough.
NFS. You would bring that up. We broke down and wrote an extension
to NFS3 to do generic extended attribute operations. It's not very
complicated, it's the way you'd do it if you were working from a
blank coding form, but the protocol purists shake their heads and
tisk at it. As others have suggested, NFS may just not be the right
scheme for an arbitrarily extended attribute world.
On the downside, experiance bears out the view that the big issue
with extending attributes is teaching commands such as cp, install,
tar, and backup to deal with them appropriatly. Worse, commands like
emacs which use the ole link-rename-create-unlink-rename scheme
are assured to drop attributes. Essentially, the system has to be
attribute aware, not just the file system or application.
BTW: All spelling errors are mine, and should not reflect on
my employer or any other individual.
--Casey Schaufler voice: (650) 933-1634 casey@sgi.com fax: (650) 933-0170
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/