Hi,
On Wed, Oct 25, 2000 at 02:34:40AM +0200, Andreas Gruenbacher wrote:
> On Tue, 24 Oct 2000, Stephen C. Tweedie wrote:
> > [...]
> > Our proposed kernel API looks something like this:
> > [...]
>
> The main point I see here is the ability to manipulate a number of
> attributes as an atomic operation. I really don't understand what you mean
> by an ordered attribute list.
Simply something like an ACL, which can be manipulated either as an
entire list or (in some cases) entry by entry. There are filesystems
where you can manipulate individual ACEs without touching the rest of
the ACL (like the VMS filesystem or NCPFS, and we already have NCPFS
in the kernel).
> There are a number of features that could be implemented at the syscall
> interface. The things I have in mind range from get-and-set, manipulating
> multiple attributes atomically, to some sort of mini-language specifying
> more complicated transactions. Some sort of database transactions is right
> out of the question.
Agreed. Of all these, the one which is absolutely required is the
get-and-set; with that, an application can perform read/modify/write
cycles reliably even in the presence of multiple accessors.
> All these things complicate the EA syscall interface and implementation
> considerably. One main goal for the syscall interface for me was
> simplicity. I still fail to see a real need for any of the features
> mentioned above.
Two processes want to add an ACE. They run the ACL tool. Both tools read
the ACL, add their ACE, and write. One wins the race, and the others'
write is lost.
You can avoid this with the get-and-set, because in that case you do
1) read the ACL into X
2) modify it into Y
3) do an atomic get-Z-and-set-Y
4) if Z != X, somebody beat you to the write, so go back to step 1.
> Stephen, maybe you can enlighten me why you think your interface is the
> minimal interface required?
> I think different concepts (like Posix ACLs and NTFS ACLs) should be
> reflected as different EAs, not different namespaces.
Two things.
First, the API level is not the place to enfore the "store in
different EA" decision. We could if we were designing the filesystem
world from scratch, but we aren't. Why not? Well, the question is
--- who gets to decide which attribute to store the different ACEs in?
We already have a bunch of different filesystems which have their own
mechanisms for storing ACLs. We will have people mounting those
filesystems under Linux. You just can't say "OK, I'll join this
distributed filesystem but I'll not honour your ACLs unless you store
them in such-and-such an EA."
Storing different concepts in different EAs makes a ton of sense
inside the filesystem, though.
Secondly, there's a difference between the namespace for the
authentication tokens, and the semantics of the ACLs. Take NFSv4, for
example. On the wire, all of its tokens --- ownership and group
ownership information, ACE identifiers and so on --- are specified as
UTF8 strings, typically of the form "user-identifier@domain". There's
a perfectly clean mapping between local unix IDs and ids of the form
"decimal-uid@local-domain", but in the more general case you would
typically be using something like "username@kerberos-realm". Given
that we have a mapping for local uids, we can still parse the POSIX
ACL API, but we also need to be able to store these other forms of
authentication token in *the same type of ACE*. In other words, NFSv4
presents us ACLs whose "concepts" are consistent but whose identifiers
may be different. My API allows for that cleanly.
> So instead of having
> different namespaces for Posix ACLs, Capabilities, Mandatory Access
> Control labels etc. you just have different attributes (say, "system.acl",
> "system.cap", "system.mac". For NTFS ACLs, you have yet another attribute
> name (say, "system.ntfs_acl").
We are very nearly agreeing: where you define "system.acl",
"system.ntfs_acl" and "system.mac", I was defining "ATF_POSIXACL",
"ATF_NFSACL" and "ATF_ATTR:mac".
However, I still disagree *fundamentally" about exposing this stuff
through names like "system.acl". We already have filesystems which
implement ACLs, and filesystems which implement user and system
extended attributes. If you enforce a mapping between those in the
API, then the API becomes useless for other filesystems which map
those things differently. What do you do about filesystems which have
ACLs as a different attribute space entirely, but which don't have the
concept of system ACLs?
NFSv4, for example, has ACLs and named attributes as completely
different concepts, but does not have the concept of "system" named
attributes at all.
> > The extended attribute patch currently on the acl-devel group simply
> > doesn't give us the ability to do extended attributes on any
> > filesystem other than ext2, because it has such specific semantics.
> > I'd rather avoid that, and I'd rather do so without adding a profusion
> > of different ACL and attribute syscalls in the process.
>
> I really don't see why you think the semantics are "specific". They are
> simple--on purpose, and for good reason. What makes them specific in your
> opinion?
They don't let you manipulate AFS or NFSv4 ACLs. They don't let you
manipulate extended attributes on filesystems that don't conform to an
artificial new set of naming conventions (user attributes have to
start with a letter, system attributes have to start with "$"). They
don't let you set MACs except through the EA mechanism which I've
already explained doesn't necessarily map to other filesystems.
Cheers,
Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
