Re: nfs permission escalation?

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:hey,
:
:I just experienced the following:
:
:server# echo '/mnt -ro' >> /etc/exports && /etc/rc.d/mountd reload
:Reloading mountd config files.
:
:server% cd /mnt && mkdir foo && chmod 500 foo
:server% cp /bin/echo foo && chmod 555 foo/echo
:
:client# mount -t nfs server:/mnt /mnt
:client# /mnt/echo foo
:echo: permission denied
:
:client% /mnt/echo foo
:foo
:
:client# /mnt/echo foo
:foo
:
:
:Explanation:
:A directory on the server is only r-x------, the mount is exported with 
:default settings (=rootsquash).  Root on the client can't execute a 
:binary from this directory.
:
:Everything fine till here.  Now I run the binary as the user on the 
:client:  I am allowed to run it.  Still fine.
:
:Now if I try to run it as root (again), it suddenly works.  I guess that 
:our namecache isn't aware of the rootsquashing and thus grants access to 
:the cached vnode.
:
:Hope I explained this bug correctly :)
:
:cheers
:   simon

    Yes, this is simply because from the client's point of view,
    root is allowed to access everything, while from the server's point
    of view, any root cred accesses will be converted to UID -2.

    So if the data is not cached on the client, the request is passed
    to the server and rejected because uid -2 has no access to it.

    But once the data is cached on the client, the client can access
    it as root even if the server would otherwise not allow that.

    There are cache timeouts involved here too.  Once the attribute
    cache times out I'm not sure whether the next root-access will 
    succeed or not... probably not.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>