Why does nfsroot result in nonzero root user euid?

[Carl Miller]

> Stuart> On the target you are root, but not when you run stuff of the
> Stuart> nfs mounted root.
> 
> So the root squash parameter causes the NFS server negotiate with the
> client to change its euid, and the client is trusted to do so.

That doesn't sound right at all...

> I wonder why they didn't just have the server do a translation...

Yes, all the translation *should* be happening on the server.

What the squash option in an NFS server does is change the EUID of
reads and writes.  With root_squash, if the NFS client is accessing
a file as root, then the NFS server treats the access as if it's from
the squashed-to UID.  The idea is to prevent clients claiming to be
root from having carte blanche to do whatever they want to the
filesystem.

NFS squash shouldn't do anything to non-filesystem-related permissions
of processes executing on the client.

....unless....

The mount binary you're running is on the NFS filesystem?  Is it by
any chance set-uid?  If so, there you go.  When it gets executed, the
client honors the setuid bit, but because the NFS server squashes root
to UID 500, the client sees the file as set-uid-500, not set-uid-root.
The client then happily sets mount's EUID to 500.

Try clearing the set-uid bit on the mount binary, and see if that
fixes the problem.  Potential downside: now only root will be able to
run that mount binary usefully -- mount is supposed to be set-uid root,
and can't allow normal users to take mount actions without that, even
if /etc/fstab says it should.


                              -----Carl

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com