Monitoring space token ACLs

I have extended my space token monitoring to pick up the ACLs (technically the GlueVOInfoAccessControlBaseRule) about each space token that is published in the information system fro each site, SE and VO. This is updated each day and you can see the table of results here. The point of this is to make it easier (i.e. no horrible ldapsearch'ing) to check the deployment status of the tokens and the ability of certain VOMs roles to write files into them. Of course, this assumes that the advertised permissions do in fact match those on the SE, which in turn relies on the GIPs being correct. YMMV.

sgm and prod pool accounts

I've been a bit confused of late regarding what the best course of action is regarding how to deal with sgm and prod pool accounts on the SEs, in particular, dCache. As an example, Lancaster have run into the problem where a user with an atlassgm proxy has copied files into the dCache and has correspondingly been mapped to atlassgm:atlas (not atlassgm001 etc, just plain old sgm). Non-sgm users have then tried to remove these files from the dCache and have been denied since they are simple atlas001:atlas users. The default dCache file permissions do not allow group write access. This raises a few issues:

1. Why is atlassgm being used to write files into the dCache in the first place?

2. Why are non-sgm users trying to remove files that were placed into the dCache by a (presumably privileged) sgm user?

3. When will dCache have ACLs on the namespace to allow different groups of users access to a bunch of files?

The answer to the 3rd point is that ACLs will be available some time next year when we (finally) get the Chimera namespace replacement to PNFS. ACLs come as a plugin to Chimera.

The interim solution appears to be just to map all atlas users to atlas001:atlas, but this obviously doesn't help the security and traceability aspect that pool accounts are partially trying to solve. Since DPM supports namespace ACLs, we should be OK with supporting sgm and prod pool accounts. Of course, this requires that everyone has the appropriately configured ACLs, which isn't necessarily the case, as we've experienced before.

Comments welcome below.

It now seems that ATLAS don't want the DPM ACL changes for the atlas/generated directory. I got ths email from Simone:

On 9 Feb 2007, at 03:54, Simone Campana wrote:

Hi Graeme. 

We discussed this with the DPM devels. 
The reason to change the generated 
directory ACL is to allow the SGM to run 
SAM test. Not to complicate things furher, 
I would request to have the change only to the
atlas/dq2 directory with the production 
role and leave alone the generated directory. 
I will change instructions accordingly and deal
with SAM test differently. 

So it seems that the ACL script should only be run on the dq2 directory - at least that simplifies things greatly for the sites.

So I had suggested to the DPM team that what I needed to do to overcome the error reported in the blog was to add a new ACL, which would allow the ordinary (i.e., non-VOMS role) ATLAS users to write into the generated directories, regardless of who had first created them.

The magic command to do this is:

# dpns-setacl -m d:g:atlas:rwx /dpm/gla.scotgrid.ac.uk/home/atlas/generated

(Your domain may vary...)

The intital "d" means "default" and ensures that this ACL is inherited by all newly created sub-directories (and the "g" means a "group" ACL).

I set this two days ago and found a friendly Melbourne ATLAS user (thanks Glen!) to help me test this - and it worked. In the 2007-02-07 directory, which had been created with the atlas/Role=lcgadmin group Glen was able to write a file as a normal ATLAS user.

So, the current situation for fixing up your DPM for ATLAS involves:

1. Running the new script, which doesn't mess up the ACL owning user and group of the "root" directory - you can get than from http://www.physics.gla.ac.uk/~graeme/misc/update_acl_formysql.tar.gz.
   
2. Then adding the additional ACL above to the generated directory.
   

Of course, you might just want to wait for some more complete fix to emerge from WLCG.

In addition, I have also raised the issue of the dq2 directory with ATLAS, but have yet to receive any response - so at the moment I haven't added any ACLs here.

Most of the DPM sites will be aware that Atlas recently asked for everyone to update the ACLs on the home/atlas/dq2 and home/atlas/generated directories of the DPM namespace. The fix to do this was initially provided as a binary (provided by the DPM devels) that would parse a configuration file and make changes in the MySQL database. Initially there were a few problems with this:

1. No source code was provided with the binary (actually being called a script in the atlas email). even though the operation was tagged as being EXTREMELY DELICATE.
2. The binary had already been through one bug fix after limited deployment., so confidence in it wasn't exactly high.
3. Subsequent bugs have been found after running it in the UK. For example, the looking at the atlas/generated directory on the Glasgow DPM:

[...]
drwxrwxr-x 298 143 103 0 Feb 06 11:43 2007-01-29
drwxrwxr-x 13 143 103 0 Feb 06 11:34 2007-01-30
drwxrwxr-x 1 117 117 0 Jan 31 22:40 2007-01-31
drwxrwxr-x 2 117 117 0 Feb 01 22:46 2007-02-01

GID 103 is the normal atlas group. GID 117 is atlas/Role=lcgadmin. (Thanks to Graeme for this).

It would have been better if the tools had been available for site admins to perform this ACL update without having to resort to direct connections to the MySQL DB. dpm-setacl could have been used, but since this does not have a recursive mode it wouldn't have been all that user friendly to use.

I think this is another example of where the administration tools of the storage middleware are lacking.