Subject: [nfsv4] PUTFH+SECINFO_NO_NAME+OPEN(fh) issue

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 7 Nov 2007 10:58:34 -0500

This is my take on this troublesome compound.

The problem here is that with the rules as we have them
OPEN(fh) needs to be able to return WRONGSEC but is not
allowed to.

It isn't clear how to fix this.  Two proposals that have 
not seemed satisfactory are:

    Mike has proposed that we legislate this case out of
    existence and say that the OPEN(fh) (and really
    any operation) can return UNSAFE_COMPOUND or a new 
    error BAD_COMPOUND.

    I've suggested allowing all those ops to return 
    WRONGSEC.

The problem here is that we have to create an exception to the
normal expectation that PUTFH would check for WRONGSEC to
allow it to be used as a preliminary to SECINFO_NO_NAME.
Once you allow this, then you seem stuck with the case that
Jeff has proposed in which someone takes things one step
further and tries to use the current fh after SECINFO_NO_NAME.

If we were earlier in the process I would propose that 
SECINFO_NO_NAME be redefined not to use the cfh, i.e. that
it takes the fh to work on as a separate parameter.  Then
you wouldn't need the exception for PUTFH+SECINFO_NO_NAME
and PUTFH+OPEN(fh) would result in WRONGSEC on the PUTFH,
whether the SECINFO_NO_NAME was interposed or not.  It seems
like it is too late in the game to make that sort of change 
to the XDR definition of SECINFO_NO_NAME.

So an alternative that would address this but is less 
disruptive than changing the XDR definition of SECINFO_NO_NAME.
is to specify that SECINFO_NO_NAME consume the current fh.
That is, if there is a saved fh, that becomes the current fh,
while if there isn't, the COMPOUND has no cfh after the 
SECINFO_NO_NAME.  I assert that would not be disruptive since
any compound that would be disrupted by that change is one
that uses the cfh after SECINFO_NO_NAME, i.e. is one that has
exactly the problem we are trying to address.

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 07 Nov 2007 13:27:29 -0600

> exactly the problem we are trying to address.

Given that it is the PUTFH/RESTOREFH that is to receive
the WRONGSEC error:

--
2.6.3.1.7.  Put Filehandle Operation + Anything Else

    "Anything Else" includes OPEN by filehandle.

    The security policy enforcement applies to the filehandle specified
    in the put filehandle operation.  Therefore PUTFH must return
    NFS4ERR_WRONGSEC in case of security tuple on the part of the
    mismatch.
--

I would amend your suggestion slightly such that a saved
filehandle is not consumed and therefore the SECINFO_NO_NAME
leaves the current filehandle in an "undefined" state similar
to if no PUTFH had been done.

This way the client would need to construct the
COMPOUND as:
	PUTFH, SECINFO_NO_NAME, PUTFH, OPEN(by-FH)

and therefore the second PUTFH would receive
the WRONGSEC error if appropriate.

Spencer

---

From: Mike Eisler <[email-masked]>
Date: Wed, 7 Nov 2007 11:38:13 -0800 (PST)

> to if no PUTFH had been done.

I do like the idea that the use of SECINFO* causes the
current filehandle to be cleared. This completely, simply, and
unambiguously solves the problem Jeff raised.

I too would rather the server not use the saved filehandle when
the current filehandle is cleared by SECINFO*.

While this changes the implementation of current and saved
filehandles on the server from a simple stack to two separate
registers, that's complexity tradeoff that is easy to accept.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 7 Nov 2007 15:17:10 -0500

>     I've suggested allowing all those ops to return 

A minor digression: Is it going to be awkward to reconcile the limits on
which operations can return WRONGSEC with the ability for administrators
to change security requirements at any moment?

If somebody sends me a PUTFH, GETATTR, OPEN, and the administrator asks
to tighten security on the export just as I'm hanging out in GETATTR
waiting for the #%*#$^! ldap server to tell me who uid 2815 is, I might
be tempted to return WRONGSEC on the OPEN when I get to it.  I dunno.

Hm.  A paragraph here seems to have been the victim of some sort of
minor editing trainwreck:

	"... Therefore PUTFH must return NFS4ERR_WRONGSEC in case of
	security tuple on the part of the mismatch.  This avoids the
	complexity adding NFS4ERR_WRONGSEC as an allowable error to
	every other operation."

I think what was intended was something like?:

	"... Therefore PUTFH must return NFS4ERR_WRONGSEC in the case of
	a security triple mismatch.  This avoids the complexity of
	adding NFS4ERR_WRONGSEC as an allowable error to every other
	operation."

--b.

---

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 7 Nov 2007 15:31:48 -0500

> be tempted to return WRONGSEC on the OPEN when I get to it.  I dunno.

I think the spec is telling you to seriously resist the temptation.

Of course, if Mephistopheles promises you unimaginable wealth just for
violating the v4.1 spec, you'll have to make your own decision.

Seriously, I think the logic of the spec is that the implementation,
at the point of PUTFH or crossing into a part of the namespace with
new security restrictions, checks at that time whether your current
security flavor is acceptable.  From a performance point of view 
doing anything else is a problem anyway.

I know there are people whose concern for security is such that 
that would not be acceptable.  I think if you are dealing with them, 
you will have to return DELAY and when the PUTFH is done as part
of the follow-up, give him WRONGSEC then.

-----Original Message-----
From: J. Bruce Fields [mailto:[email-masked]] 
Sent: Wednesday, November 07, 2007 3:17 PM
To: Noveck, Dave
Cc: [email-masked]
Subject: Re: [nfsv4] PUTFH+SECINFO_NO_NAME+OPEN(fh) issue

--b.