[glue-wg] ACLs, ACLs, everywhere [WAS: Comparison with CIM]

[Maarten.Litmaath at cern.ch]

Hi Paul,

> [...]
> 
> Yes, absolutely right: one can mark-up the ACL entries.  This gets around 
> the "identifying the rules" problem, but creates another one.  It would 
> require the client to hold some database of known ACL schemata (AFS vs NTFS 
> vs...), along with a mapping between user operations and corresponding 
> required ACE entries for each of the supported ACL schema.

Not each, just the ones it cares about.  Analogy: a product wrapper may have
the same text in multiple languages - just pick the one(s) you understand.
The texts need not even be equivalent, e.g. because of different laws or
cultures in different countries.

> > > Moreover, since a site might publish authz info with any (valid) ACL
> > > format, a client must be able to understand *all* potential ACL formats
> > > and how the
> >
> > Here I do not agree.  A client can simply ignore stuff it does not
> > understand.
> 
> Perhaps, as a fall-back policy, a client can simply "try its luck" and see 
> whether the operation succeeds.

Right.  If the understandable information did not rule out success, the client
might give it a try.

> > For example, we now publish both "VO:atlas" and "VOMS:/atlas" 
> > ACBRs, the latter being ignored by old clients.
> 
> Whilst you're quite correct in saying that publishing both "VO:atlas" 
> and "VOMS:/atlas" allows for backward compatibility, I suspect that this is a 
> special case. 
> 
> In general, one cannot precisely map an ACE from one ACL schema to another;  
> for example, what POSIX ACE should be published for the following AFS ACE?
> 	GlueAccessControlEntry: /DC=ch/DC=cern/.../CN=somebody::lkd

There is no need to map it to another ACL schema.  The service is saying:
if you happen to understand AFS ACLs, I can tell you that the given DN
has "lkd" permissions.  (There should be a schema prefix like "afs:").

> > A service can support multiple interfaces.
> 
> Yes, but only if the service happens to support both interfaces, and this is 
> only helpful if all clients understand at least one of the interfaces.
> 
> The equivalent would be if a filesystem happens to support multiple ACL 
> schemata (e.g., both AFS and NTFS ACLs) so both could be published.  This may 
> be technically feasible (anything's possible!), but I doubt any filesystem 
> supports more than one ACL schema.

I should have been clearer.  In my GLUE example the "posix"/"afs"/"ntfs"/...
schemas need not mean that the server actually runs such a file system or
equivalent: I used the schema to define a policy _language_.

> [...]
> > > If we want to publish an authz mapping between users and a service, I
> > > feel it should be at a VO level.  What are the use-cases for *publishing*
> > > finer-grain authorisation?  ...and are they reasonable?
> >
> > We already have finer-grain authorization today, viz. per VOMS FQAN, and
> > that is certainly what e.g. ATLAS and LHCb are expecting. 
> 
> Ah!  But these aren't really ACLs as don't specify the permitted operations.  

The operations are implicit:

    posix:rwx
    afs:rlidw(a)
    ntfs:rwxd(p)

More interesting ACLs might look like this:

    srmv22:/someVO/admin:rw
    srmv22:/someVO:w

They would be for a space that can be used as a write buffer by the whole VO,
but as a read buffer only by privileged FQANs within the VO.

> They're more like the mapping between user-community and some object within 
> the Glue schema.  This is more what I meant by at a "VO level": (sorry, I 
> should have used the term user-community or "UserDomain").
> 
> 
> > Moreover, MyProxy servers even publish the individual DNs that they trust!
> 
> Ah, sorry, I don't know enough about MyProxy, but isn't this a trust issue 
> rather than one of authorisation?

It is another illustration that the VO level is not fine-grained enough for
GLUE.