Subject: RE: subset of ACLs functionality

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 17 Jul 2002 15:38:18 -0700

Mike Upfer writes: 
> >>>>> "Dave" == Dave Noveck <Noveck> writes:
> 
>     Dave> Although you have a change bar on the line, I suspect this
>     Dave> is not something you changed, but the phrase "if an ACCESS
>     Dave> or OPEN request" is misleading and should be changed.  ACL
>     Dave> checking applies to READ, WRITE, RENAME, REMOVE, SETATTR,
>     Dave> LOOKUP, etc., not just ACCESS and OPEN.
> 
> The edit was to add a comma after "succeeds".
> 
> Why does the ACL check need to be done for READ and WRITE, since it
> was already done at OPEN?

I don't see any statement in the spec that the same credentials have 
to be used on a READ or WRITE as were used on the OPEN.  I would expect
that in most cases that would be true but it's not guaranteed, and
therefore you had better check when the IO is done.  

Even if there were such a rule and the server checked tha the credentials
are the same, there is still the issue of responding to permission
changes.  Waiting unitl close and a new OPEN might not be desirable.

Another issue is the special stateid's.  I know the spec says
you are supposed to do an open but since there is no real stateid,
how can the server check that you are doing that.

--- <Stuff deleted> ----

>     Dave> Last paragraph of section 5.9, change "should not" to "must
>     Dave> not"
> 
> How strong is this "must" (since it's not in capital letters)?  I
> don't think we understand ACL interoperability real well, so I want
> to avoid situations where a server is declared to be non-conformant
> because of a security issue even if everyone agrees that the server's
> behavior is useful.

That's why I didn't use capital letters.  It just seems too wishy-washy
to have a guiding principle, and then have its voice be so weak.  You
can ignore the guiding principle, but if it says "must" at least it's 
making an effort to command your attention.

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 17 Jul 2002 17:53:51 -0500

> therefore you had better check when the IO is done.  

True and as you point out most clients will use the same credentials
or they won't get what they expect.

> changes.  Waiting unitl close and a new OPEN might not be desirable.

From a Unix perspective, check at OPEN is exactly what is desired,
right?  We are all familiar with the old applications that like to
open() then chmod such that the file can not be read/written and this
works for v2/v3 when the credential matches the owner of the file but
what you have suggested may potentially break then unless the v4
server implements the same behavior as in v2/v3.

Spencer