LOCK, LOCKU, CLOSE, OPEN upgrade, OPEN downgrade, DELEGRETURN, etc.
Dave Noveck writes:
I think that when we address this issue, we address all of it.
Some areas that havn't been mentioned, so far:
Credential identity requirement for open upgrade.
Credentials for open-downgrade.
Credential requirements, if any, for delegation-return.
-----Original Message-----
From: Mike Eisler [mailto:email2mre-ietf@yahoo.com]
Sent: Monday, April 23, 2007 12:02 PM
To: nfsv4@ietf.org
Subject: What credentials should a setuid process use after fork (was
Re:[nfsv4] Client state security and the SSV)
--- Rick Macklem <rmacklem@uoguelph.ca> wrote:
>
>
> On Sat, 21 Apr 2007, Mike Eisler wrote:
> [stuff snipped]
> >
> > I was thinking of proposing that we require that CLOSE, LOCK,
> LOCKU,
> > etc. be done with the same credential that issued OPEN instead of
> > upgrading the SSV. That is not necessary to solve the problem
> > Trond identified. Still, it is something that I think we should
> > consider negotiating when EXCHANGE_ID is issued.
> >
> What about the following case:
> - "rick" opens file "foo" for writing, gets OpenStateId-foo using
> "rick"
> credentials
> - process forks off long running child process to run in background
> - this process inherits open of "foo"
> - this process does a setuid "daemon" (which has credentials in a
> keytab
> so they don't expire during the long run)
> - "rick" logs out and "rick" credentials go away
> - child process terminates, doing a Close of OpenStateId-foo
I don't know about FreeBSD and other kernels, but last I checked
Solaris, the "ucred" of the user that opened the file and generated the
file descriptor is get with the open descriptor. All subsequent
operations, even through the vnode layer, use the "ucred" assigned
to the open file descriptor.
If that wasn't the case, then given that NFSv3 has no OPEN operation,
how would it work for user joe to open a file he owns with mode
bits 0600, run a setuid process to steve, and then that process tries
to issue I/O?
>
> For a case like this, requiring Close to use the same credentials as
> the
> Open would force the client to re-open all files when a setuid
> occurs,
> using the new credentials ("daemon" for the above case). Suppose
No, because under the scenario I gave, re-opening the file for steve
would not work. The open file descriptor has joe's credentials,
so issuing the CLOSE with joe's credential is quite feasible.
> "daemon"
> doesn't have permissions to write "foo"? (This might be reasonable,
> since
> "daemon" is some generic credentials in a keytab, used for long
> running
> processes and might not have access.)
>
> It seems the the big change between RFC3010 and RFC3530 w.r.t. state
> handling was for cases like the above. Requiring the Close to use the
The state handling in RFC3510 and the security was underspecified.
It was a surprise to be that some clients were handling the
joe/steve scenario differently that Solaris.
> same credentials as Open, seems to break it?
>
> rick
|