Re: [nfsv4] NFS4ERR_WRONGSEC inconsistency - LINK and RENAME

["Mike Eisler" <[e-mail]>]

> From: Noveck, Dave
> Sent: Sunday, April 13, 2008 9:09 AM
> To: 'Trond Myklebust'; Mike Eisler
> Cc: [e-mail]
> 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
[e-mail]
https://www.ietf.org/mailman/listinfo/nfsv4