Subject: Creds and open files

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 6 Jun 2001 08:19:40 -0700

This is not a continuation of the philosophical dispute
that Mike Eisler and I have been having, so don't hit
delete just yet.

There is another case that we haven't been considering
that needs to be considered.

Rather than considering open/change-identity/IO, how
about open/change-identity/open where the two opens
are of the same file.

As it stands, if the opens have the same access
specified (or more generally if the second is a 
subset of the first), then the client does no
OPEN operation on the server (I guess he does 
have to do an ACCESS) since we have a one open-file
for each file-lockowner combination.  (we have
talked about possibly doing something else but 
that is what we have now).  So it seems like the
IO-as-same-principal rule (whether in SHOULD or
MUST form) would force us to switch this to a 
model in which you can have one open-file for 
each file-lockowner-principal combination.

Another version of this is where the two opens
differ in access.  open-for-read/change-identity/
open-for-rdwrt.  Right now the client is supposed 
to do an OPEN which the server is supposed to 
implement an an upgrade. The credentials for the
open presumably the new ones  But then what 
credentials would you use for the IO?  Of course,
if we went to a one-stateid-per-file-lockowner-
principal-triple, the you would get separate
stateid sequences for each and everything could
work find with each IO using the proper stateid 
for its principal.    

Of course, this issue has interactions with the
whole open upgrade/downgrade issue (prompted by the
difficulties that Windows derived servers have with
OPEN_DOWNGRADE).  I think we'll probably have to 
address those together.

---

From: Mike Eisler <[email-masked]>
Date: Wed, 06 Jun 2001 09:40:40 -0700

> subset of the first), then the client does no
                                        ^^^^^^^
> OPEN operation on the server (I guess he does
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> for each file-lockowner combination.  (we have

Are you talking about the case where the first OOPEN
results in delegation of subsequent OPENs to the client?

If you mean the non-delegated case,
then I don't see how this can work, nor do I see 
where in the spec it says so (but it is a vast spec, so
I may have missed it).

The nfs_lockowner4 is composed of the client-id
and the "owner", which "may be a thread id, process id,
or other unique value." In UNIX, it
will be a process id unique to the client.

It seems to me that when a second process opens
the same file, even it it is the same principal,
the client needs to send the OPEN. Otherwise, a
unique stateid/sequence id space cannot be
constructed, which is necessary to implement
mandatory locking.

> each file-lockowner-principal combination.

I've always assumed this was the case.

While we are opening cans of worms,
it also means that when a UNIX process forks,
the underlying filesystem will need to issue a new
OPEN before it attempts a READ or WRITE, because
a new process id is a new nfs_lockowner4. As
a related aside, in UNIX file locks are not inherited
by child processes. In any case, there is an issue
with how the OPEN is done in the forked
process case. There needs to be a way to OPEN the
file by file handle, and the current specification
doesn't allow it, except in reboot scenarios. 

> work find with each IO using the proper stateid

Interesting. From the UNIX client perspective,
I see two scenarios:

	1. a process changes its access to the
		file via fcntl(). In Solaris,
		one can even change the share
		reservation deny mode with fcntl().
		The process also changes its
		principal identity. In this
		case, the credentials used when
		the file descriptor was created
		should be used for sunbsequent
		READs and WRITEs.

	2. a process changes its principal
		idenity, while still holding
		open a file opened under a
		previous identity. Now the same
		process opens the same file
		with the new identity.  

It seems to me that life would be
much easier if section 8.10,
Open Upgrade and Downgrade, were
revised such that the implicit coalescing
of OPENs did not happen. Instead, there could
be an explicit OPEN_UPGRADE to handle scenario 1
(with or without the principal identity change),
and to hadle scenario 2, a fresh OPEN by pathname
be issued which does not result in coalescing of second
OPEN with the first OPEN. But there was problably
a technical reason that I've forgotten why
the coalescing is in place.

	-mre