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

[Paul Millar]

Hi Maarten,

On Tuesday 06 May 2008 22:56:37 Maarten.Litmaath at cern.ch wrote:
> > > An example mixing grid authorization notions with POSIX ACL syntax:
> > >	[snip: similarly published ACLs]
> > ... which illustrates the problem with publishing ACLs nicely.
> >
> > On seeing an entry like:
> > 	GlueAccessControlEntry: /DC=ch/DC=cern/.../CN=somebody::rwx
> >
> > does a client assume that the ACL is POSIX one [... or ... or ...]
>
> We agree that ACL formats and semantics are not yet well-established at the
> grid level, so we should not try and quickly get something into GLUE 2.0.

Agreed, but I would say the problem is a little deeper: with ACLs for certain 
objects, the ACL semantics may be implementation specific and outside of 
Glue's (or "the grid's") control.  For this reason, it may be impossible for 
harmonisation of semantics to occur.

> Note, however, that the semantics could be explicitly put into each schema,
> [...]

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.

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

> 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

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

[...]
> > 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.  
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?

Cheers,

Paul.