Re: [nfsv4] NFS4ERR_WRONGSEC inconsistency

> > So I think you have two questions:
> >
> > 1) Can security policies be on name-pattern-defined classes of
objects?
> >
> > 2) Is the saved fh protected in the same way as current fh?
> >
> > So my take is:
> >
> > 1Y, 2Y: CREATE, LINK, RENAME
>
> I think it is:
>
> 1Y, 2Y: REMOVE
> 
> Why isn't REMOVE among the list? The target could have a policy.

My intention was that REMOVE was implicitly included in all the options,
just as LOOKUP is.

> Why is CREATE on the list? If the object doesn't 
> exist, it has no policy. If it does exist, then 
> NFS4ERR_EXIST is what must be returned.

Under 1Y, objects can implicitly have policies based on their names.
With the example of "*.secret" requiring kerberos, AUTH_SYS creation of
"big.secret" would return WRONGSEC.

> Why are LINK and RENAME on the list? The saved 
> fh is protected.

> LINK is linking one of the two filehandles; we've 
> already checked their policies. Note that if the 
> target name exists, we return NFS4ERR_EXIST. This 
> is the same as CREATE.

Here I was thinking of a name-based policy where the link matched the
link pattern.

> RENAME: security policies should not be protecting 
> the rename of the policied object. SECINFO is not 
> that smart.

RENAME identifies an existing object by name.  If the caller would get
WRONGSEC doing a LOOKUP of that object, he certainly should get one
renaming it.

> > 1Y, 2N: CREATE, LINK, RENAME, RESTOREFH

> I think it should be:

> 1Y, 2N: REMOVE, LINK, RENAME, RESTOREFH

> for the same reasons as the previous 1Y, 2Y case.

OK.

> > 1N, 2Y: none of the above

> Dave noted this should have had RENAME. I'm not 
> seeing it. A RENAME amounts to adding a directory 
> entry and deleting a directory entry. If REMOVE 
> and CREATE are not on the list, why should RENAME 
> be on the list?

REMOVE was intended to be implicitly on the list as discussed above.

The difference between CREATE and RENAME is similar to that between
CREATE and OPEN.  RENAME works on an existing object which may have
previously acquired a policy.

> > So I think it is:

> > 1N, 2Y: none of the above

I think it would be RENAME and REMOVE.

> > 1N, 2N: LINK, RENAME, RESTOREFH

> I agree.

> So while eliminating RESTOREFH from the list of 
> operations that can return NFS4ERR_WRONGSEC is 
> going to create a lot editing work for me, I agree 
> that 1N, 2Y is the easiest case and the sanest way 
> to deal draft-21's current inconsistency.

I agree.

-----Original Message-----
From: Mike Eisler [mailto:mre-ietf@eisler.com] 
Sent: Sunday, April 13, 2008 3:55 PM
To: nfsv4@ietf.org
Subject: Re: [nfsv4] NFS4ERR_WRONGSEC inconsistency - LINK and RENAME

> From: Noveck, Dave
> Sent: Sunday, April 13, 2008 9:09 AM
> To: 'Trond Myklebust'; Mike Eisler
> Cc: nfsv4@ietf.org
> Subject: RE: [nfsv4] NFS4ERR_WRONGSEC inconsistency - LINK and RENAME

>> Also, just out of curiosity, why do we have RESTOREFH in the above 
>> two
>
>> lists? Aren't you pretty much guaranteed to get a WRONGSEC error on 
>> the filehandle before you get round to the SAVEFH?
>
> I think this may relate to the issue of LINK and RENAME.  If you 
> create an object and continue to use it in the COMPOUND, you could 
> conceive, since it is not atomic, that between two ops the server 
> changes his security policy for the object in question (if you can 
> ever get WRONGSEC subsequently, it has to change some time, so it 
> might be before the COMPOUND is done), but the protocol has decided, 
> in order to simplify client implementations, to avoid the possiblity 
> of getting WRONGSEC for the current fh.  At any time that for the 
> current fh, you are guaranteed not to get the error on a current fh 
> once vetted when established.  You could apply the same to the saved 
> fh, but you don't have to.  Not protecting the saved fh in this way 
> would only mean that you had to check the error at RESTOREFH and 
> anywhere that the saved fh was actually used (only LINK and RENAME, I 
> think)

Makes sense.

> So I think you have two questions:
>
> 1) Can security policies be on name-pattern-defined classes of
objects?
>
> 2) Is the saved fh protected in the same way as current fh?
>
> So my take is:
>
> 1Y, 2Y: CREATE, LINK, RENAME

I think it is:

1Y, 2Y: REMOVE

Why isn't REMOVE among the list? The target could have a policy.

Why is CREATE on the list? If the object doesn't exist, it has no
policy. If it does exist, then NFS4ERR_EXIST is what must be returned.

Why are LINK and RENAME on the list? The saved fh is protected.

LINK is linking one of the two filehandles; we've already checked their
policies. Note that if the target name exists, we return NFS4ERR_EXIST.
This is the same as CREATE.

RENAME: security policies should not be protecting the rename of the
policied object. SECINFO is not that smart.

> 1Y, 2N: CREATE, LINK, RENAME, RESTOREFH

I think it should be:

1Y, 2N: REMOVE, LINK, RENAME, RESTOREFH

for the same reasons as the previous 1Y, 2Y case.

> 1N, 2Y: none of the above

Dave noted this should have had RENAME. I'm not seeing it. A RENAME
amounts to adding a directory entry and deleting a directory entry. If
REMOVE and CREATE are not on the list, why should RENAME be on the list?

So I think it is:

1N, 2Y: none of the above

> 1N, 2N: LINK, RENAME, RESTOREFH

I agree.

So while eliminating RESTOREFH from the list of operations that can
return NFS4ERR_WRONGSEC is going to create a lot editing work for me, I
agree that 1N, 2Y is the easiest case and the sanest way to deal
draft-21's current inconsistency.

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