Re: NFS4 authentification / fsuid

[J. Bruce Fields]

On Thu, Aug 30, 2007 at 04:42:33PM +0200, Jan Engelhardt wrote:
> 
> On Aug 30 2007 10:29, Trond Myklebust wrote:
> >On Thu, 2007-08-30 at 16:12 +0200, Jan Engelhardt wrote:
> >> 
> >> with NFS3, there is this 'root hole', i.e. any person who has a root 
> >> account (perhaps by use of a laptop) can mount an export (let's say this 
> >> export had the "root_squash" option), and still have a look at the user 
> >> files, because he can locally setuid() into another user.
> >> 
> >> So I was looking for alternatives. CIFS is my favorite candidate, but it 
> >> has a few issues right now. So does sshfs and about everything I have 
> >> come across. Since I remember NFS4 can use KRB5 authentification, my 
> >> question is, will the NFS(4) server process run with an fsuid equal to 
> >> the user that authenticated?
> >
> >NFSv3 should work fine with krb5 too, but that won't solve your problem
> >with setuid: kerberos saves the TGT in a file on /tmp, so root can still
> >suid and grab your cred (and the same goes for CIFS).
> 
> Hm? I do not see this problem with CIFS. The user may have local
> root, but on the server, he only has his non-root account on the
> server, and as such, can only operate on the server using this
> non-root fsuid. Did I miss something? (Especially the /dev/mem thing
> is not quite clear to me.)

The server will run with an fsuid equal to the user that authenticated,
you're correct.  So if you require krb5 access on an export, then nfs
access to a file on the export should be permitted only on rpc's that
are authenticated using credentials of a user with permission to access
the file.

Trond's pointing out that when you give the client your krb5 credentials
you're trusting it to do only what you tell it to with them.  You have
to trust the client's kernel at the very least, and also root on that
client, for the forseeable future.

--b.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/