Re: [nfsv4] NFS4ERR_CLID_INUSEwhen SetClientID changesauthenticationmechanisms

mike@eisler.com

Message-ID: <41C74B98.4040702@eisler.com>
Date: Mon, 20 Dec 2004 14:00:56 -0800
From: Mike Eisler <mike@eisler.com>
Subject: Re: [nfsv4] NFS4ERR_CLID_INUSEwhen	SetClientID	changesauthenticationmechanisms

J. Bruce Fields wrote:

> 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

Or from the same host.

> stateid, then the CLOSE will succeed and the user's client will start

I can't tell which side of the issue you are arguing. But your
point does argue for the principal issuing the CLOSE be the same as that
of the principal that created the state sequence via OPEN.

> getting BAD or OLD STATEID errors.  Does that mean the application
> reading the file on the user's behalf will fail?   And can a

Yes.

> carefully-written client limit client limit the damage just to that?

A client is written to re-established state due to a Denial of Service
attack is at best hard to write, and at worst an exercise in futility.
The only ways to solve this are:

- If you must use APIs that cause stateids to change, then
   set the ACL such that only you and other trusted users can
   issue such NFSv4 operations. Or:

- Use the proper credential on stateid modifying operations,
   and on the server side, enforce the credential.

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