W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2005

Re: Issue 71, Clarify what servers may and may not do with privileges when BIND is used

From: Elias Sinderson <elias@cse.ucsc.edu>
Date: Wed, 27 Apr 2005 14:54:44 -0700
Message-ID: <42700A24.6030502@cse.ucsc.edu>
To: 'webdav' <w3c-dist-auth@w3.org>

Eric Sedlar wrote:

> I think that BINDing's across security domains will in practice only 
> occur across multiple instances of a product from a single vendor. [...]

I would think that this will be the case most, but not all, of the time. 
However, even if the respositories are of the same pedigree, their 
respective configuration or product version differences may impact the 
ability to preserve principles and permissions.


> In those cases, I don't see why a BINDing across across security 
> domain will necessarily behave any differently.
> --Eric
> 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 Wednesday, 27 April 2005 21:54:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:34 UTC