On Tue, Apr 20, 2010 at 09:52:10AM -0600, lattera wrote: > First of all, thanks a lot for taking a look into this. I really appreciate > the time and effort. > > On Tue, Apr 20, 2010 at 9:39 AM, Tom Haynes <[email protected]> wrote: > > > RPC: ----- SUN RPC Header ----- > > RPC: > > RPC: Record Mark: last fragment, length = 216 > > RPC: Transaction id = 3359327889 > > RPC: Type = 0 (Call) > > RPC: RPC version = 2 > > RPC: Program = 100003 (NFS), version = 4, procedure = 1 > > RPC: Credentials: Flavor = 1 (Unix), len = 40 bytes > > RPC: Time = 19-Apr-10 16:40:04 > > RPC: Hostname = shawn-desktop > > RPC: Uid = 0, Gid = 0 > > > > This means you are doing the action as root, which makes > > sense as it is a mount.
Automounting is supposed to use the triggering process' euid as the credentials. At least for the NFSv4 code paths I'm pretty sure it will never use the kcred/zcred during the mount process unless either: a) the mount is not an automount, or b) the automount triggering process is running as root. How is the mount being done/triggered on the client side? In any case, in order for a mount to succeed, the client has to be able to traverse from the pseudo-root to the directory being mounted, and has to be able to get attributes of the directory being mounted. If at any point the client were using the kcred/zcred during the mount process then root/nobody would need read/access permissions to the relevant directories, though I would consider the use of kcred/zcred a bug unless root were doing the mount / triggering the automount. Also, there's share ACLs, which come in two flavors: the one for NFS shares, based on client hostnames/IP addresses/netgroup memberships, and the one for CIFS, based on ZFS ACLs. Nico -- _______________________________________________ nfs-discuss mailing list [email protected]
