Subject: [nfsv4] NFS4ERR_WRONGSEC inconsistency - LINK and RENAME

From: "Mike Eisler" <[email-masked]>
Date: Sat, 12 Apr 2008 10:02:21 -0700 (PDT)

Chapter 15 says:

| NFS4ERR_WRONGSEC                  | LOOKUP, LOOKUPP, OPEN, PUTFH, |
|                                   | PUTPUBFH, PUTROOTFH,          |
|                                   | RESTOREFH                     |

But Chapter 18, SECINFO says:

  client request receives NFS4ERR_WRONGSEC.  The operations which may
  receive this error are: LINK, LOOKUP, LOOKUPP, OPEN, PUTFH, PUTPUBFH,
  PUTROOTFH, RESTOREFH, RENAME, and indirectly READDIR.

I will change SECINFO to refer to Chapter 15 for the list of operations
so that these inconsistencies are avoided. The READDIR thing is
about rdattr_error and I will clarify that.

I wanted to see how folks on the mailing list feel about LINK and RENAME
being among the list. The errors/ops inspection team apparently decided
these should not return NFS4ERR_WRONGSEC. I cannot find the rationale.

But I suspect the rationale is the same as for CREATE and REMOVE
not being on the list.

If CREATE is not on the list, then LINK should not be on it, because
both are adding directory entries.

If CREATE and REMOVE are not on the list, then RENAME should be on it,
because RENAME is adding directory entries like CREATE, and
potentially removing directory entries like LINK.

So the rationale for CREATE not being on the list? Here is a stab:

The target name is presumed to not exist (if it did, NFS4ERR_EXIST would
trump other errors, even if the target name had a different security
policy). Therefore the security policy of the directory filehandle is used,
and the put directory filehandle operation is where we enforce the policy.

The stab for REMOVE not being on the list:

While the target name might have a policy separate from the parent
directory, since the name is going to be removed the policy of the
parent directory trumps the child.

-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/

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

---

From: Trond Myklebust <[email-masked]>
Date: Sat, 12 Apr 2008 14:03:14 -0400

>   PUTROOTFH, RESTOREFH, RENAME, and indirectly READDIR.
<snip>
> and the put directory filehandle operation is where we enforce the policy.

Shouldn't this argument also apply to OPEN?

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?

Cheers
  Trond

---

From: "Mike Eisler" <[email-masked]>
Date: Sat, 12 Apr 2008 11:35:58 -0700 (PDT)

> Shouldn't this argument also apply to OPEN?

OPEN can create files.

> filehandle before you get round to the SAVEFH?

The security policy is allowed to change between the PUT* operation
that injected the filehandle, and the RESTOREFH.

---

From: Trond Myklebust <[email-masked]>
Date: Sat, 12 Apr 2008 15:11:13 -0400

> > Shouldn't this argument also apply to OPEN?

<confused>
        CREATE can make directories, special files, symlinks. Just like
        OPEN, it also changes the current filehandle. What's the
        significant difference that means one should and the other
        shouldn't return WRONGSEC?
</confused>

> that injected the filehandle, and the RESTOREFH.

I fail to see how this is any different from the security policy
changing between PUTFH and the following operations that take a current
filehandle argument.
IOW, why is there a difference here between the behaviour of the current
filehandle and that of the saved filehandle?

If you're arguing that there is such a difference then you need to
explain why RENAME and LINK shouldn't return WRONGSEC: they both
explicitly use the saved filehandle.

  Trond

---

From: "Mike Eisler" <[email-masked]>
Date: Sat, 12 Apr 2008 12:28:38 -0700 (PDT)

>         shouldn't return WRONGSEC?

And OPEN can also not create files. So since LOOKUP can return
WRONGSEC, it follows that OPEN has to be able to return WRONGSEC,
but only when the file name already exists, and only when OPEN by
fh is not being used.

I can clarify this.

> changing between PUTFH and the following operations that take a current

(Unfortunately, I missed most of the meetings of the errors inspection
team last fall due to travel to places in odd time zones. But
you were on the inspection team so I'm hoping you can answer why
the team settled on what we have in the spec now.)

Perhaps an argument was made that RESTOREFH can use a fh
that does not come from PUT*, e.g. CREATE. Potentially a
security policy might get set on
the filehandle between the SAVEFH and the RESTOREFH.

Another argument is that it is one think to check security
policy at file handle injecting operation and another to check
it at every operation.

We can explain how to recover from RESTOREFH returning NFS4ERR_WRONGSEC,
but it is hard to explain for all other operations. Nor is there
much appeal for increasing the number of operations that can return
NFS4ERR_WRONGSEC.

> explicitly use the saved filehandle.

I don't see an equivalence between WRONGSEC being returned by
RESTOREFH and LINK/RENAME. I do see an equivalence
between WRONGSEC being returned by CREATE/REMOVE and LINK/RENAME.

---

From: Trond Myklebust <[email-masked]>
Date: Sat, 12 Apr 2008 15:54:32 -0400

> but only when the file name already exists, and only when OPEN by

So, you are effectively saying that the security policy may differ for a
regular file and its parent directory? What kind of applications do we
see for this? I ask because this will have an effect on the client
implementations: I've generally assumed that most security policies will
tend to be applied on a filesystem-wide basis.

> the filehandle between the SAVEFH and the RESTOREFH.

Yes, but the same arguments apply to the current filehandle. A security
policy can be set at any time during the execution of the COMPOUND: I'm
just confused as to why we want to handle the saved filehandle any
differently from the current filehandle when this happens.

I'm not sure that we really plumbed the depths of this in the review.

> much appeal for increasing the number of operations that can return

I absolutely agree that it would be great to keep the number of
WRONGSECs down.

> between WRONGSEC being returned by CREATE/REMOVE and LINK/RENAME.

See above. I'm arguing that you are treating the saved filehandle
inconsistently: either you should decide that changes in security policy
_do_ apply to it, or you have to decide that they don't (as is the case
for the current filehandle).

Cheers
  Trond

---

From: "Noveck, Dave" <[email-masked]>
Date: Sun, 13 Apr 2008 09:08:41 -0400

> > The target name is presumed to not exist (if it did, NFS4ERR_EXIST 
> > would trump other errors, even if the target name had a different 
> > security policy). Therefore the security policy of the directory 
> > filehandle is used, and the put directory filehandle operation 
> > is where we enforce the policy.

> Shouldn't this argument also apply to OPEN? 

No, because of the fact that OPEN can be and often is applied to
existing objects.

One question that governs which errors are valid is how you think that
security poliies are assigned to portions of filesystems.  The way I had
been thnking about it was that policies would be assigned to existing
objects and inherited from parent objects to subordinate objects.

So if I create and object within a directory it would have the same
security as the parent directory until someone changed  that security
policy by some action (command line on the server) outside the scope of
v4.x.  Similarly, there is no way to create a file system object with
v4.x.  You create a directory which is part of the current filesystem
and then somehow later something on the server (e.g. a mount) transforms
that into a junction to a new fs.

On the other hand, you could allow a policy that says directory entries
whose string ends in ".secret" have a different security policy than
those that don't, in which case LINK, CREATE, and RENAME are now very
different from a WRONGSEC perspective.

> 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)

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

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

1N, 2Y: none of the above

1N, 2N: LINK, RENAME, RESTOREFH

-----Original Message-----
From: Trond Myklebust [mailto:[email-masked]] 
Sent: Saturday, April 12, 2008 2:03 PM
To: Mike Eisler
Cc: [email-masked]
Subject: Re: [nfsv4] NFS4ERR_WRONGSEC inconsistency - LINK and RENAME

<snip>
> The target name is presumed to not exist (if it did, NFS4ERR_EXIST 
> would trump other errors, even if the target name had a different 
> security policy). Therefore the security policy of the directory 
> filehandle is used, and the put directory filehandle operation is
where we enforce the policy.

Cheers
  Trond

---

From: "Noveck, Dave" <[email-masked]>
Date: Sun, 13 Apr 2008 11:23:01 -0400

> I ask because this will have an effect on the client
> implementations: I've generally assumed that most 
> security policies will tend to be applied on a 
> filesystem-wide basis.

I have a similar assumption but the question for the protocol is not
what most servers will do but what is allowed.  

RFC3530 specified WRONGSEC as a valid return from OPEN, which indicate
to me that it was always intended that policies could change within file
systems and on individual files.

BTW, OPENATTR can't return WRONGSEC so you can't change policies at that
point.  I guess you are free to give one at a lookup within the
attribute directory unless the spec specifically says that this isn't
allowed, which would make sense to me. 

-----Original Message-----
From: Trond Myklebust [mailto:[email-masked]] 
Sent: Saturday, April 12, 2008 3:55 PM
To: Mike Eisler
Cc: [email-masked]
Subject: Re: [nfsv4] NFS4ERR_WRONGSEC inconsistency - LINK and RENAME

On Sat, 2008-04-12 at 12:28 -0700, Mike Eisler wrote:
> WRONGSEC, it follows that OPEN has to be able to return WRONGSEC, but 
> only when the file name already exists, and only when OPEN by fh is 
> not being used.
> 
> I can clarify this.

> >> > 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

> > changing between PUTFH and the following operations that take a 
> > current filehandle argument.
> 

> team last fall due to travel to places in odd time zones. But you were

> on the inspection team so I'm hoping you can answer why the team 
> settled on what we have in the spec now.)
> 
> Perhaps an argument was made that RESTOREFH can use a fh that does not

> come from PUT*, e.g. CREATE. Potentially a security policy might get 
> set on the filehandle between the SAVEFH and the RESTOREFH.

> Another argument is that it is one think to check security policy at 
> file handle injecting operation and another to check it at every 
> operation.
> 
> We can explain how to recover from RESTOREFH returning 
> NFS4ERR_WRONGSEC, but it is hard to explain for all other operations. 
> Nor is there much appeal for increasing the number of operations that 
> can return NFS4ERR_WRONGSEC.

> > IOW, why is there a difference here between the behaviour of the 
> > current filehandle and that of the saved filehandle?
> >
> RESTOREFH and LINK/RENAME. I do see an equivalence between WRONGSEC 
> being returned by CREATE/REMOVE and LINK/RENAME.

Cheers
  Trond