Re: [nfsv4] NFS4ERR_CLID_INUSEwhen SetClientID changesauthenticationmechanisms

bfields@fieldses.org

Date: Thu, 16 Dec 2004 12:01:51 -0500
Subject: Re: [nfsv4] NFS4ERR_CLID_INUSEwhen	SetClientID	changesauthenticationmechanisms
Message-ID: <20041216170151.GA7357@fieldses.org>
From: "J. Bruce Fields" <bfields@fieldses.org>

Trond wrote:
> > Recall that at one point the Linux client was sharing open_owners
> > between different credentials. Turns out that was impractical for
> > various reasons, but I still find nothing in the RFC that forbids it.

On Thu, Dec 16, 2004 at 08:03:50AM -0800, Mike Eisler wrote:
> OK. I was objecting more to the assertion that you don't need access
> rights to the file. I think you either need access rights, or need the
> access rights that were checked at the time the file was opened.
>
> I look it this way. In an operating environment like POSIX, if we had
> just local file systems, it would not be possible for user A to unlock
> user B's locks.  File systems going over a network break the tight
> control of the operating environment for sure, but  they should at
> least offer some security to prevent state corruption from
> unauthorized users.

If I deploy a NFSv4 server at the University of Michigan, I'll want to
use the UMICH.EDU kerberos realm, which has hundreds of thousands of
principals.  The chance that one of them is compromised or otherwise in
malicious hands is pretty much 100%.

Also, I'm likely to want to have files on my server that are readable by
any authenticated user.

If a user establishes some state to read such a file, it's probably not
hard to guess their stateid and use it to send a CLOSE request from
another host.  If the server doesn't associate any principal with the
stateid, then the CLOSE will succeed and the user's client will start
getting BAD or OLD STATEID errors.  Does that mean the application
reading the file on the user's behalf will fail?   And can a
carefully-written client limit client limit the damage just to that?

--b.

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4