Hi,
On Fri, Oct 27, 2000 at 10:46:26AM +0200, Andreas Gruenbacher wrote:
> > On Thu, Oct 26, 2000 at 10:21:22PM +0200, Andreas Gruenbacher wrote:
> > > I'm aware of that problem. That's why I think test-and-set is less
> > > painfull, although it involves more overhead.
> >
> > OK, I'm convinced.
>
> I would like to research whether a versioning interface (to ensure
> consistent updates) is possible at all, so I will take a closer look at
> the NFSv4 spec.
OK.
> > > I also _really_ don't like different EA families to have different
> > > semantics
> >
> > Think about the read(2) system call. Is it atomic? Well, yes for
> > datagram sockets, no for streams, depends on the read size for
> > pipes... and it's blocking or not depending on the type of the file
> > and the fcntl() flags you may or may not have set on it.
>
> You have the same operations on files, and usually, you get to choose the
> semantics yourself (as the user of the API). In the EA case, the semantics
> would mostly be enforced by the kernel, depending on the EA name.
No --- in both cases it's a mix of the two. For regular files, you
get zero choice as a user. For sockets, you get some choice ---
O_NONBLOCK, for example --- but other choices are forced upon you (eg.
atomicity is not an option you can enable or disable arbitrarily).
In the EA case, too, you get to choose which semantics you want when
you specify the namespace (and hence specify the object you are
accessing); the rest is forced upon you from there.
> > 2) the moment somebody comes up with a _new_ attribute that you hadn't
> > thought of, you need to resort to new syscalls or you can't access
> > them.
>
> The moment somebody comes up with a new system EA, that somebody will have
> to implement the right policy in the kernel (as an EA handler in my
> implementation). System EAs are not just EAs that happen to have a
> different name. Manipulations of them are tightly controlled by the
> kernel.
You keep talking about them as if they are all implemented through
your EA handler. If you take that as your starting point, then of
_course_ you'll end up with such an API.
What about filesystems which implement MAC labels and/or ACLs, but
not named attributes? Why should the application coerce the ACL into
an artificial attribute, just for the filesystem to have to unpick it
again?
> > In NFSv4, authentication tokens are UTF/8 character strings, not Unix
> > uids. You can map a Unix ID to an NFSv4 name quite easily: it would
> > come out as "[EMAIL PROTECTED]" or "[EMAIL PROTECTED]". However, you
> > _also_ want to be able to deal with remote users who do not have local
> > unix uids, and there simply isn't a mapping between uids and those
> > remote names.
> >
> > So, any ACL API capable of dealing with NFS ACLs must not only provide
> > for uids, it must also be able to accept other tokens (UTF/8 strings
> > in this case, but also NT SIDs in the case of SMB ACLs) if the user
> > demands it.
>
> There seems to be a fundamental problem here. You are talking about
> manipulating ACLs through the kernel interface that have no meaning to the
> kernel itself. The kernel just doesn't know anything about
> "[EMAIL PROTECTED]", not even for the local domain. The kernel also
> can't even translate from username to uid. It knows only about uid's;
> that's what access control decisions are based on. The Posix ACLs I have
> implemented are meaningful to the kernel, so the kernel can deal with
> them.
That's simply not true. We have code to prove it: NFSv4 and AFS
already work on Linux. The trick, of course, is that the names
involved are only meaningful to the filesystem itself, not to the rest
of the kernel --- but that's fine if what we are producing is an API
to the filesystem.
On a distributed filesystem, you *HAVE* to be able to specify access
rights for remote users. Think about a big NetApps server box
connected to a number of different departments in an organisation.
I may have a file owned by my account "sct@development", and I may
want to make it readable to "joe@support". These names are meaningful
to the filesystem. If they have no meaning to the local kernel, then
that just means that ACEs using those names will never be applied to
local users. It is still imperative that the local user has a way to
set rights for remote users.
> I have to do some backgroud reading on NFSv4, but right now I really don't
> know what the kernel could ever do with "[EMAIL PROTECTED]" other than
> pass that on in an NFS RPC or such. Imagine if the kernel did store
> "[EMAIL PROTECTED]" on ACLs on the filesystem. When an access control
> decision needs to be done, the kernel simply has no idea about what
> "[EMAIL PROTECTED]" means.
The VFS doesn't, but the filesystem does. In NFSv4, what happens at
the moment is that the kernel says "I don't know who the local user
is" and asks a local GSS daemon to do a kerberos authentication on the
user. Once that is complete, both the client and the server have an
authenticated and secure ID for the user of the form "username@REALM".
This is the whole point --- the kernel doesn't know what the
authentication IDs look like, but the filesystem does. The API *must*
not be specified exclusively in terms of the kernel's own limited view
of credentials.
> > > Yes, and my position is just the opposite. I believe in keeping the EA
> > > interface simple
> >
> > What's so complex about "name=value" pairs as provided by the ATR_USER
> > family? In the API I proposed, ATR_USER _is_ the basic named
> > attribute API. ATR_SYSTEM is the privileged named attribute API.
> > ATR_POSIXACL is the standard POSIX ACL API.
>
> It's that in your proposed ACL namespace you have vastly differing
> semantics, differing operations, in fact, a completely different API. The
> user/system/privileged namespace has simple EA semantics, while the ACL
> namespace is a world by itself.
Umm, look again --- your proposed spec does the same, saying that the
semantics change on a name-by-name basis for system EAs via
installable handlers in the kernel.
And my API is not at all "different": in each case it's a series of
assignments of values to attributes. The attribute family specifies
what kind of attribute. Named attributes are specified by name. ACEs
are specified by credentials. Nothing fancy there.
Cheers,
Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
