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!