View source for Access control for CASTOR storage elements

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 <tt>dteam</tt> 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 <tt>dteam</tt>
VO:
 12983000000     1003000000      n.a     srm-dteam.gridpp.rl.ac.uk

You can use the <tt>srmping</tt> 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 <tt>srm-dteam.gridpp.rl.ac.uk</tt> is a SRMv2.2 compliant storage system based on CASTOR.

= Finding out how storage is organized =

You can use the <tt>srmls</tt> 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 <tt>srmls</tt> on this directory returns:
 srm client error:
 java.lang.Exception: Return status:
  - Status code:  SRM_TOO_MANY_RESULTS
  - Explanation:
but we '''can''' list the <tt>generated</tt> 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 CASTOR SRM we first create our own directory. If we do not do this then SRM will
store the files in <tt>generated</tt> directories, over which we have little or no control.
  srmmkdir srm://srm-dteam.gridpp.rl.ac.uk/castor/ads.rl.ac.uk/test/dteam/disk0tape0/janjust
The URL for this directory will be used throughout the rest of this page, hence we abbreviate it to
 SRM=srm://srm-dteam.gridpp.rl.ac.uk/castor/ads.rl.ac.uk/test/dteam/disk0tape0/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-castor-file file://$PWD/myfile
  guid:0e56765a-5e1c-495e-a997-4495a4f06f18
which returns the LFC GUID for the file upon success.

'''Note''': the LFC location is <tt>/grid/pvier/janjust</tt> which was actually a mistake. However, the LFC
allows me to write to this directory even though I used a <tt>dteam</tt> proxy !!

(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) <tt>lcg-cr</tt> command. Please also note
that the <tt>srmcp</tt> 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: 
# SRM-level
# 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]].

 $ srm-get-permissions $SRM/myfile
 # file  : srm://srm-dteam.gridpp.rl.ac.uk/castor/ads.rl.ac.uk/test/dteam/disk0tape0/janjust/myfile
 # owner : dteam001
 owner:dteam001:RWX
 user:dteam001:RWX
 group:dteam:RWX
 other:RW


Just for the fun of it, let's list a file which we did not create ourselves:
 $ srm-get-permissions srm://srm-dteam.gridpp.rl.ac.uk/castor/ads.rl.ac.uk/test/atlas/atlasTest/nopolicy2
 # file  : srm://srm-dteam.gridpp.rl.ac.uk/castor/ads.rl.ac.uk/test/atlas/atlasTest/nopolicy2
 # owner : gtf
 owner:gtf:RW
 user:gtf:RW
 group:sysgroup:R
 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 are subtle differences!

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

= Modifying the permissions =

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

Instead we use <tt>dpns-setacl</tt>. 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 <tt>group</tt> bits: <tt>g::0</tt>
* remove the mask (to make sure other groups do not inherit permissions): <tt>m:0</tt>
* remove the <tt>other</tt> bits: <tt>o::0</tt>

 dpns-setacl -m g::0,m:0,o::0 /dpm/nikhef.nl/home/pvier/janjust/myfile

DPM and the <tt>dpns-setacl</tt> 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 <tt>srmcp '''-2'''</tt> flag: without it the <tt>srmcp</tt> 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 <tt>pvier</tt> 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 <tt>default</tt> 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 <tt>group</tt> 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 <tt>srmcp</tt> command wants to send a checksum of the file to the DPM Gridftp back-end, which it does not support.