I do not wish to offend, O Great Ones....8^)
I think I've found an...infelicity in the nfs client
implementation of 2.2.5. I browsed some 2.3 code and
didn't see it changed so I'm bringing it up here.
Here's the scenario: I'm running a Linux NFS client
against Tru64. Tru64's file creation semantics are:
-use the UID of the creating process
-use the GID of the parent dir
(I'm leaving out irrelevant details regarding sticky
bits and so forth)
Linux's normal (i.e. non-NFS) behavior seems to be (I
can't find this doc's anywhere):
-use the UID of the creating process
-use the GID of the creating process
However, when creating a file/dir on an NFS mount from
Tru64, I got Tru64's semantics happening, not Linux's.
AIX (which uses the same semantics as Linux) didn't
have this "problem".
Looking at the NFS client code, I see the uid/gid
getting set to -1 before being sent to the server.
Glancing over the server code, it looks like we'll
accept a client's UID/GID if sent and generate them
otherwise. Presumably Tru64's NFS server also accepts
a UID/GID from the client and that's how AIX must be
implementing this.
I can definitely see why you (the NFS client) might
want to say "Just do whatever the server does", but I
think we'd also like to say "Do it my way".
However, I'm no NFS expert (or indeed a Linux/Unix
expert)--can someone tell me if I'm way off here? If
Linux is technically correct and AIX is just "nice to
use" I can accept that. Otherwise however, I'd like
to propose a mount flag that allows the selection of
behavior. Say "server behavior" vs "client-type
behavior". Or maybe it would have to be
system-wide...?
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
-
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/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:36 EST