Re: NFS client won't set GID on file create

From: Trond Myklebust (trond.myklebust@fys.uio.no)
Date: Wed Mar 22 2000 - 16:49:33 EST


>>>>> " " == David Rysdam <drysdam@yahoo.com> writes:

>> Setting the uid/gid here is a bug on many NFS servers (they
>> refuse to create the file), hence we leave it to the server to
>> choose.

> No offense intended, but isn't this a little lame? We cripple
> the NFS client because some servers are broken? Why not make a
> mount option for nfs that specifies "use normal Linux
> (i.e. bsd) semantics" vs "use server semantics (whatever they
> are".

As long as most servers decide to use our default uid/gid this should
not be necessary.
 
>> The fsuid/fsgid will be passed to the server via the RPC
>> credential scheme, and most (but not all) servers choose to use
>> this for the file creation.

> You lost me here.

The Sun RPC scheme which lies beneath NFS, relies on the client being
able to identify itself in some way. The most common (but by no means
the only) is to use UNIX uid/gid + 16 groups. Normally the server will
do something like an setfsuid() setfsgid() to the values of the
uid/gid passed for RPC authentication before treating our NFS request.

>> Note: In my NFSv3 client patches, it's possible to define
>> NFSD_BROKEN_UID in fs/nfs/dir.c, to cause the attributes to be
>> set explicitly in the CREATE call. Because of the
>> afore-mentioned problems with some servers it is not enabled by
>> default.

> I didn't see any code like that in the two (admittedly old)
> kernels I looked in. Are these patches private to you or are
> they included in a later kernel?

See http://nfs.sourceforge.net, you'll find a full FAQ.

> The reason I ask is that my preference (albeit only marginally
> informed) is for this to be a per-mount option, not a global
> one. That way broken servers can be dealt with without
> crippling ALL NFS mounts on a given client. If no one else is
> handling this, I could take a whack at it (as a first kernel
> project--I'm getting all tingly!)

By all means do if you think it is needed. I've only gone as far as
making it a compile option.

Cheers,
  Trond

-
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:37 EST