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

[Maarten.Litmaath at cern.ch]

Hi Paul,

> > An example mixing grid authorization notions with POSIX ACL syntax:
> >
> >     GlueAccessControlEntry: /DC=ch/DC=cern/.../CN=somebody::rwx
> >     GlueAccessControlEntry: /someVO/Role=admin::rwx
> >     GlueAccessControlEntry: other::r-x
> >     GlueAccessControlEntry: default:user::rwx
> >     GlueAccessControlEntry: default:group::rwx
> >     GlueAccessControlEntry: default:other::r-x
> >     GlueAccessControlEntry: mask::rwx
> >
> > Or with AFS ACL syntax:
> >
> >     GlueAccessControlEntry: /DC=ch/DC=cern/.../CN=somebody::rlidwa
> >     GlueAccessControlEntry: /someVO/Role=admin::rlidwa
> >     GlueAccessControlEntry: other::rl
> >
> > Or with NTFS ACL syntax:
> >
> >     GlueAccessControlEntry: /DC=ch/DC=cern/.../CN=somebody::rwxdpo
> >     GlueAccessControlEntry: /someVO/Role=admin::rwxdpo
> >     GlueAccessControlEntry: other::rx
> 
> ... 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 (user can do all operations), 
> or a AFS one (user can't do "lida"), or an NFS one (can't do "dpo"), or [...] 
> A client simply can't tell.  A grid (e.g., WLCG) might standarise on one but 
> this is irrelevant: GLUE is about cross-grid standardisation, right?

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.
Note, however, that the semantics could be explicitly put into each schema,
e.g. like this:

        GlueAccessControlEntry: posix:/DC=ch/DC=cern/.../CN=somebody::rwx
        GlueAccessControlEntry: afs:/DC=ch/DC=cern/.../CN=somebody::rlidwa
        GlueAccessControlEntry: ntfs:/DC=ch/DC=cern/.../CN=somebody::rwxdpo

> 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.
For example, we now publish both "VO:atlas" and "VOMS:/atlas" ACBRs, the latter
being ignored by old clients.  A service can support multiple interfaces.

> permissions map to the operation the client wants to undertake.  For 
> operation X, what permissions are needed for POSIX-like ACLs, and for AFS and 
> for NTFS, and for NFS, and for GPFS, and for [...]; what about operation Y, 
> what permissions are needed for POSIX-like [...]?
> 
> Even if the information is published and somehow clients can understand all 
> possible information, the published ACLs may still (from practice and legal 
> reasons) be incomplete; even if the client has successfully understood the 
> ACLs there's no guarantee that they will be able to use the service.

True, there can be other restrictions that are not published.

> 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.  Moreover, MyProxy servers
even publish the individual DNs that they trust!