Re: Issue 71, Clarify what servers may and may not do with privileges when BIND is used (was: Moving forward on BIND)

I agree with this.

But what about conventions about whether resource permissions may be 
changed when new bindings are created to it?
  - e.g. I have a share directory
  --> I add a binding into the share directory, to a file that's in an 
unshared directory

MAY the server change the permissions on the target file as a result of 
a bind operation?  That's what I expect the user might normally want, 
but it should probably be the responsibility of the client, not the 
server.  So we should say the server MUST NOT change the permissions?

Lisa

On Apr 26, 2005, at 2:21 PM, Elias Sinderson wrote:

>
> Julian Reschke wrote:
>
>> [...] most of the open Bugzilla issues should have been closed [...]
>
> 71, Clarify what servers may and may not do with privileges when BIND 
> is used
> As ACLs are defined on resources, not bindings, I don't see how the 
> spec can say much that hasn't already been said. There are, however, 
> potential issues with bindings across different security domains. If 
> anything, I would advocate a restrictive approach to permissions. That 
> is, permissions on bindings SHOULD default to those of the resource 
> where possible, but MAY be restricted when bindings are made across 
> namespaces with different permissions. Permissions MUST NOT be granted 
> or extended in the above scenario. As I see it, this is the prudent 
> thing to do in this situation. The only other option would be to 
> forbid bindings across security domains that cannot maintain the 
> existing permissions exactly as they are on the resource (if, for 
> example, a given principledid not exist and could not be created).
>
> Comments?
>
>
> Best,
> Elias
>

Received on Thursday, 12 May 2005 18:32:48 UTC