Access control for CASTOR storage elements

From PDP/Grid Wiki
Jump to navigationJump to search

This page is part of an investigation on How to control access rights for LFC/SRM files .

Note: CASTOR is currently not being used in the Netherlands. It is included in this investigation for the sake of completeness. Also, as there are no Dutch CASTOR systems we cannot use proxies for the Dutch VOs that were used for the other storage elements. For CASTOR we will use a dteam proxy.

Finding out which storage systems are available

There are only a few CASTOR storage systems in use within EGEE. A Google search came up with one that is accessible for the dteam VO:

12983000000     1003000000      n.a     srm-dteam.gridpp.rl.ac.uk

You can use the srmping command to get some basic information about a storage system

$ srmping -2  srm://srm-dteam.gridpp.rl.ac.uk/
VersionInfo : v2.2
SRM version:v2_7_15
backend_type:CASTOR
backend_version:2.1.7
Nb of active CASTOR threads:0

So host srm-dteam.gridpp.rl.ac.uk is a SRMv2.2 compliant storage system based on CASTOR

Finding out how storage is organized

You can use the srmls command to figure out how the storage is organized:

$ srmls -l srm://srm-dteam.gridpp.rl.ac.uk/
srm client error:
java.lang.Exception: Return status:
 - Status code:  SRM_FAILURE
 - Explanation:  Failed for all paths

It seems that CASTOR does not allow the listing of arbitary remote directories. By looking at a file that was previously stored on this host (using lcg-lr) we guess that the directory structure starts with the prefix:

/castor/ads.rl.ac.uk/test/dteam/disk0tape0

However, an srmls on this directory returns:

srm client error:
java.lang.Exception: Return status:
 - Status code:  SRM_TOO_MANY_RESULTS
 - Explanation:

but we can list the generated directory:

$ srmls srm://srm-dteam.gridpp.rl.ac.uk/castor/ads.rl.ac.uk/test/dteam/disk0tape0/generated
 /castor/ads.rl.ac.uk/test/dteam/disk0tape0/generated/
     /castor/ads.rl.ac.uk/test/dteam/disk0tape0/generated/2009-01-23/
     /castor/ads.rl.ac.uk/test/dteam/disk0tape0/generated/2009-01-26/
     /castor/ads.rl.ac.uk/test/dteam/disk0tape0/generated/2009-03-06/
     /castor/ads.rl.ac.uk/test/dteam/disk0tape0/generated/2009-03-16/
     /castor/ads.rl.ac.uk/test/dteam/disk0tape0/generated/2009-03-18/
     /castor/ads.rl.ac.uk/test/dteam/disk0tape0/generated/2009-04-30/
     /castor/ads.rl.ac.uk/test/dteam/disk0tape0/generated/2009-05-01/
     /castor/ads.rl.ac.uk/test/dteam/disk0tape0/generated/2009-05-07/
     /castor/ads.rl.ac.uk/test/dteam/disk0tape0/generated/2009-05-14/
     /castor/ads.rl.ac.uk/test/dteam/disk0tape0/generated/2009-05-29/
     /castor/ads.rl.ac.uk/test/dteam/disk0tape0/generated/2009-06-11/
     /castor/ads.rl.ac.uk/test/dteam/disk0tape0/generated/2009-06-12/
     /castor/ads.rl.ac.uk/test/dteam/disk0tape0/generated/2009-06-19/
     /castor/ads.rl.ac.uk/test/dteam/disk0tape0/generated/2009-06-23/
     /castor/ads.rl.ac.uk/test/dteam/disk0tape0/generated/2009-06-24/
     /castor/ads.rl.ac.uk/test/dteam/disk0tape0/generated/2009-07-13/
     /castor/ads.rl.ac.uk/test/dteam/disk0tape0/generated/2009-07-15/
     /castor/ads.rl.ac.uk/test/dteam/disk0tape0/generated/2009-07-16/
     /castor/ads.rl.ac.uk/test/dteam/disk0tape0/generated/2009-07-20/
     /castor/ads.rl.ac.uk/test/dteam/disk0tape0/generated/2009-07-21/
     /castor/ads.rl.ac.uk/test/dteam/disk0tape0/generated/2009-07-22/
     /castor/ads.rl.ac.uk/test/dteam/disk0tape0/generated/2009-07-23/
     /castor/ads.rl.ac.uk/test/dteam/disk0tape0/generated/2009-07-24/
     /castor/ads.rl.ac.uk/test/dteam/disk0tape0/generated/2009-07-25/
     /castor/ads.rl.ac.uk/test/dteam/disk0tape0/generated/2009-07-26/
     /castor/ads.rl.ac.uk/test/dteam/disk0tape0/generated/2009-07-27/
     /castor/ads.rl.ac.uk/test/dteam/disk0tape0/generated/2009-07-28/
     /castor/ads.rl.ac.uk/test/dteam/disk0tape0/generated/2009-07-29/
     /castor/ads.rl.ac.uk/test/dteam/disk0tape0/generated/2009-07-31/
     /castor/ads.rl.ac.uk/test/dteam/disk0tape0/generated/2009-08-04/
     /castor/ads.rl.ac.uk/test/dteam/disk0tape0/generated/2009-08-20/

Creating your own directory in SRM-space

Before we copy a file to the DPM SRM we first create our own directory. If we do not do this then SRM will store the files in generated directories, over which we have little or no control.

srmmkdir srm://tbn18.nikhef.nl:8446/dpm/nikhef.nl/home/pvier/janjust

The URL for this directory will be used throughout the rest of this page, hence we abbreviate it to

SRM=srm://tbn18.nikhef.nl:8446/dpm/nikhef.nl/home/pvier/janjust

Copying and registering your file

Next we will copy a file to our SRM directory and register it in the LFC in one go:

$ lcg-cr -d $SRM/myfile -l lfn:/grid/pvier/janjust/my-dpm-file file://$PWD/myfile
guid:bbdad839-b2d1-46f6-95ab-5b6561f7e72f

which returns the LFC GUID for the file upon success.

(For details on how to find out how the LFC directory space is organized see Access control for the LFC)

We could also have copied the file to the SRM only, bypassing the LFC registration, using the command

lcg-cp file://$PWD/myfile $SRM/myfile

or even

srmcp -globus_tcp_port_range=20000,25000 file://$PWD/myfile $SRM/myfile

but as we needed the LFC entry as well we used the (preferred) lcg-cr command. Please also note that the srmcp command is not very well supported.

Looking at the permissions

For a file that is copied to SRM and that is registered in the LFC there are 2 sets of permissions:

  1. SRM-level
  2. LFC-level

These permissions are not directly related to each other and need to be modified separately. In this section we explain how to modify the SRM-level permissions. The LFC-level permissions are explained in Access control for the LFC.

First we try the "standard" srm-get-permissions command:

$ srm-get-permissions $SRM/myfile
srm client error:
java.lang.NullPointerException

Eh? It turns out that this is a bug: https://gus.fzk.de/ws/ticket_info.php?ticket=50779

Luckily there is another way of looking at DPM permissions:

$ export DPNS_HOST=tbn18.nikhef.nl
$ dpns-getacl /dpm/nikhef.nl/home/pvier/janjust/myfile
# file: /dpm/nikhef.nl/home/pvier/janjust/myfile
# owner: /O=dutchgrid/O=users/O=nikhef/CN=Jan Just Keijser
# group: pvier
user::rw-
group::rw-              #effective:rw-
group:pvier/Role=production:rwx         #effective:rw-
group:pvier/Role=lcgadmin:rwx           #effective:rw-
mask::rw-
other::r--

Notes

  • the dpns-* commands look at the DPNS_HOST environment variable to determine which server to talk to
  • the dpns-* commands do not use srm:// URLs so we need to strip off the srm://tbn18.nikhef.nl part

Just for the fun of it, let's list a file which we did not create ourselves:

$ dpns-getacl /dpm/nikhef.nl/home/vlemed/foo.txt
# file: /dpm/nikhef.nl/home/vlemed/foo.txt
# owner: /O=dutchgrid/O=users/O=uva/OU=wins/CN=Tristan Glatard
# group: vlemed
user::rw-
group::rw-              #effective:rw-
group:vlemed/Role=production:rwx                #effective:rw-
group:vlemed/Role=lcgadmin:rwx          #effective:rw-
mask::rw-
other::r--

When you compare it to dCache (see Access control for dCache storage elements) this looks more like "regular" UNIX permissions:

  • the file is owned by a single user
  • there are 'group' and 'other' permissions

but there is a difference

  • there are multiple group permissions

We will have to keep this in mind when we want to limit access to our files.

Multiple group permissions

Where did the multiple group permissions come from? When we do a

voms-proxy-info -all

we get

subject   : /O=dutchgrid/O=users/O=nikhef/CN=Jan Just Keijser/CN=proxy
issuer    : /O=dutchgrid/O=users/O=nikhef/CN=Jan Just Keijser
identity  : /O=dutchgrid/O=users/O=nikhef/CN=Jan Just Keijser
type      : proxy
strength  : 1024 bits
path      : /tmp/x509up_u7651
timeleft  : 7:28:03
=== VO pvier extension information ===
VO        : pvier
subject   : /O=dutchgrid/O=users/O=nikhef/CN=Jan Just Keijser
issuer    : /O=dutchgrid/O=hosts/OU=sara.nl/CN=voms.grid.sara.nl
attribute : /pvier/Role=NULL/Capability=NULL
attribute : /pvier/test/Role=NULL/Capability=NULL
timeleft  : 7:28:03
uri       : voms.grid.sara.nl:30000

which does not list these groups at all. Let's take a look at the directory permissions:

$ dpns-getacl /dpm/nikhef.nl/home/pvier/janjust/
# file: /dpm/nikhef.nl/home/pvier/janjust/
# owner: /O=dutchgrid/O=users/O=nikhef/CN=Jan Just Keijser
# group: pvier
user::rwx
group::---              #effective:---
group:pvier/Role=production:rwx         #effective:---
group:pvier/Role=lcgadmin:rwx           #effective:---
mask::---
other::---
default:user::rwx
default:group::rwx
default:group:pvier/Role=production:rwx
default:group:pvier/Role=lcgadmin:rwx
default:mask::rwx
default:other::r-x

Ah! Directories have default permissions and groups. File copied to this directory inherit these properties when they are copied into it. So if this behaviour is undesired then we need to modify the directory ACLs first.

Modifying the permissions

We would want to use the srm-set-permissions command to modify the permissions, but similar to srm-get-permissions this command does not work on DPM servers.

Instead we use dpns-setacl. Use

$ man dpns-setacl

for a full manual page, as there are many options for this command.

For our example we wish to

  • remove the default group bits: g::0
  • remove the mask (to make sure other groups do not inherit permissions): m:0
  • remove the other bits: o::0
dpns-setacl -m g::0,m:0,o::0 /dpm/nikhef.nl/home/pvier/janjust/myfile

DPM and the dpns-setacl command can do very fine-grained access control on files and directories, yet that falls outside the scope of this investigation.

Verifying access control

As the original user:

$ dpns-getacl /dpm/nikhef.nl/home/pvier/janjust/myfile
# file: /dpm/nikhef.nl/home/pvier/janjust/myfile
# owner: /O=dutchgrid/O=users/O=nikhef/CN=Jan Just Keijser
# group: pvier
user::rw-
group::---              #effective:---
group:pvier/Role=production:rwx         #effective:---
group:pvier/Role=lcgadmin:rwx           #effective:---
mask::---
other::---

so this file should now be accessible only to the user.

Now if we switch to another VO:

$ voms-proxy-init --voms vlemed
Enter GRID pass phrase:
Your identity: /O=dutchgrid/O=users/O=nikhef/CN=Jan Just Keijser
Creating temporary proxy .......................................... Done
Contacting  voms.grid.sara.nl:30003 [/O=dutchgrid/O=hosts/OU=sara.nl/CN=voms.grid.sara.nl] "vlemed" Done
Creating proxy ............................. Done
Your proxy is valid until Thu Aug  6 23:45:56 2009

and then try to copy the file

$ srmcp -2 $SRM/myfile file://$PWD/blah

we get NO error message: DPM behaves much more like regular UNIX. The file is still owned by the original user (/CN=Jan Just Keijser) and thus that user is still allowed to retrieve the file, even though the voms proxy belongs to another VO.

Note the srmcp -2 flag: without it the srmcp command tries to retrieve the file using an SRMv1 protocol, even though we have added the SRMv2 port 8446 to the SRM URL.

If we ask another member of the pvier VO to retrieve the file we see:

[tbalint] $ srmcp -2 $SRM/myfile file://$PWD/blah
Thu Aug 06 15:00:37 CEST 2009: srmPrepareToGet update failed, status : SRM_FAILURE explanation=Failed for all SURLs
Thu Aug 06 15:00:37 CEST 2009: GetFileRequest[srm://tbn18.nikhef.nl:8446/dpm/nikhef.nl/home/pvier/janjust/myfile]
status=SRM_AUTHORIZATION_FAILURE explanation=null
srm client error:
java.lang.Exception:  stopped 

i.e. other users can no longer access the file: success!

Modifying default directory permissions

We will give one more example on how to remove a default ACL from a directory:

$ dpns-setacl -d d:g:pvier/Role=lcgadmin /dpm/nikhef.nl/home/pvier/janjust/
$ dpns-setacl -d d:g:pvier/Role=production /dpm/nikhef.nl/home/pvier/janjust/
$ dpns-getacl /dpm/nikhef.nl/home/pvier/janjust/
# file: /dpm/nikhef.nl/home/pvier/janjust/
# owner: /O=dutchgrid/O=users/O=nikhef/CN=Jan Just Keijser
# group: pvier
user::rwx
group::rwx              #effective:rwx
group:pvier/Role=production:rwx         #effective:---
group:pvier/Role=lcgadmin:rwx           #effective:---
mask::---
other::---
default:user::rwx
default:group::rwx
default:mask::rwx
default:other::r-x

Now let's copy a file to this directory and check the permissions:

$ srmcp -2 -send_cksm=false file:///$PWD/myfile $SRM/myfile3

$ dpns-getacl /dpm/nikhef.nl/home/pvier/janjust/myfile3
# file: /dpm/nikhef.nl/home/pvier/janjust/myfile3
# owner: /O=dutchgrid/O=users/O=nikhef/CN=Jan Just Keijser
# group: pvier
user::rw-
group::rw-              #effective:rw-
mask::rw-
other::r--

And we see that there is only a single group entry.

Note that we used -send_cksm=false when copying a local file to the SRM. If we do not specify this parameter we see

$ srmcp -2 file:///$PWD/myfile $SRM/myfile3
GridftpClient: Was not able to send checksum value:org.globus.ftp.exception.ServerException: 
Server refused performing the request.
Custom message:  (error code 1) 
[Nested exception message: Custom message: Unexpected reply: 500 Invalid command.]
[Nested exception is org.globus.ftp.exception.UnexpectedReplyCodeException:  
Custom message: Unexpected reply: 500 Invalid command.]

yet the file IS copied to the SRM. Debugging shows that the srmcp command wants to send a checksum of the file to the DPM Gridftp back-end, which it does not support.