Difference between revisions of "Access control for CASTOR storage elements"

From PDP/Grid Wiki
Jump to navigationJump to search
 
 
(16 intermediate revisions by the same user not shown)
Line 2: Line 2:
  
 
'''Note''': CASTOR is currently not being used in the Netherlands. It is included in this investigation for the sake of completeness.
 
'''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 =
 
= Finding out which storage systems are available =
Line 8: Line 10:
 
VO:
 
VO:
 
  12983000000    1003000000      n.a    srm-dteam.gridpp.rl.ac.uk
 
  12983000000    1003000000      n.a    srm-dteam.gridpp.rl.ac.uk
 +
 +
'''Note #1''' before using the <tt>srm*</tt> commands make sure that the SRM client is at least '''2.1.0''' as otherwise most, if not all, <tt>srm*</tt> commands will fail:
 +
$ srmping -version
 +
Storage Resource Manager (SRM) Client version 2.1.0
 +
Copyright (c) 2002-2008 Fermi National Accelerator Laborator
 +
'''Note #2''' The glite 3.2 UI up to version 3.2.4 contains an '''older''' (actually, '''too old''' !) version of the srm-client than the glite 3.1 UI !
  
 
You can use the <tt>srmping</tt> command to get some basic information about a storage system  
 
You can use the <tt>srmping</tt> command to get some basic information about a storage system  
Line 16: Line 24:
 
  backend_version:2.1.7
 
  backend_version:2.1.7
 
  Nb of active CASTOR threads:0
 
  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
+
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 =
 
= Finding out how storage is organized =
Line 28: Line 36:
 
   - Explanation:  Failed for all paths
 
   - Explanation:  Failed for all paths
  
−
It seems that StoRM does not allow the listing of arbitary remote directories.  
+
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
 
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:
 
the prefix:
Line 75: Line 83:
 
= Creating your own directory in SRM-space =
 
= 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
+
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.
 
store the files in <tt>generated</tt> directories, over which we have little or no control.
−
srmmkdir srm://tbn18.nikhef.nl:8446/dpm/nikhef.nl/home/pvier/janjust
+
  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
 
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
+
  SRM=srm://srm-dteam.gridpp.rl.ac.uk/castor/ads.rl.ac.uk/test/dteam/disk0tape0/janjust
  
 
= Copying and registering your file =
 
= Copying and registering your file =
  
 
Next we will copy a file to our SRM directory and register it in the LFC in one go:
 
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
+
  $ lcg-cr -d $SRM/myfile -l lfn:/grid/pvier/janjust/my-castor-file file://$PWD/myfile
−
guid:bbdad839-b2d1-46f6-95ab-5b6561f7e72f
+
  guid:0e56765a-5e1c-495e-a997-4495a4f06f18
 
which returns the LFC GUID for the file upon success.
 
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]])
 
(For details on how to find out how the LFC directory space is organized see [[Access control for the LFC]])
Line 105: Line 116:
 
In this section we explain how to modify the SRM-level permissions. The LFC-level permissions are explained  
 
In this section we explain how to modify the SRM-level permissions. The LFC-level permissions are explained  
 
in [[Access control for the LFC]].
 
in [[Access control for the LFC]].
−
 
−
First we try the "standard" <tt>srm-get-permissions</tt> command:
 
 
  $ srm-get-permissions $SRM/myfile
 
  $ srm-get-permissions $SRM/myfile
−
  srm client error:
+
  # file : srm://srm-dteam.gridpp.rl.ac.uk/castor/ads.rl.ac.uk/test/dteam/disk0tape0/janjust/myfile
−
  java.lang.NullPointerException
+
  # owner : dteam001
−
 
+
  owner:dteam001:RWX
−
Eh? It turns out that this is a bug: https://gus.fzk.de/ws/ticket_info.php?ticket=50779
+
  user:dteam001:RWX
−
 
+
  group:dteam:RWX
−
Luckily there is another way of looking at DPM permissions:
+
  other:RW
−
$ 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 <tt>DPNS_HOST</tt> environment variable to determine which server to talk to
 
−
* the dpns-* commands do not use srm:// URLs so we need to strip off the <tt>srm://tbn18.nikhef.nl</tt> part
 
−
 
 
 
Just for the fun of it, let's list a file which we did not create ourselves:
 
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
+
  $ srm-get-permissions srm://srm-dteam.gridpp.rl.ac.uk/castor/ads.rl.ac.uk/test/atlas/atlasTest/nopolicy2
−
  # file: /dpm/nikhef.nl/home/vlemed/foo.txt
+
  # file : srm://srm-dteam.gridpp.rl.ac.uk/castor/ads.rl.ac.uk/test/atlas/atlasTest/nopolicy2
−
# owner: /O=dutchgrid/O=users/O=uva/OU=wins/CN=Tristan Glatard
+
  # owner : gtf
−
  # group: vlemed
+
  owner:gtf:RW
−
  user::rw-
+
  user:gtf:RW
−
  group::rw-              #effective:rw-
+
  group:sysgroup:R
−
group:vlemed/Role=production:rwx                #effective:rw-
+
  other:R
−
  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"
 
When you compare it to dCache (see [[Access control for dCache storage elements]]) this looks more like "regular"
 
UNIX permissions:
 
UNIX permissions:
 
* the file is owned by a single user
 
* the file is owned by a single user
 
* there are 'group' and 'other' permissions
 
* there are 'group' and 'other' permissions
−
but there is a difference
+
but there are subtle differences!
−
* there are '''multiple''' group permissions
 
  
 
We will have to keep this in mind when we want to limit access to our files.
 
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 =
 
= 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.
+
Use
 +
srm-set-permissions -h
 +
to get a list of options for this command.
 +
$ srm-set-permissions -type=CHANGE -group=NONE -other=NONE $SRM/myfile
 +
Return code: SRM_INVALID_REQUEST
 +
Explanation: Group 500 does not exist
 +
Don't you just love these kind of error messages?
 +
Some experimentation shows that the <tt>-group=NONE</tt> part is wreaking havoc:
 +
$ srm-set-permissions -type=CHANGE -other=NONE  $SRM/myfile
 +
returns no errors, but ...
 +
$ 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:RW
 +
other:R            # <------------- !!!!!
 +
it also did not do what we expected: the <tt>other</tt> permissions are still '''R''' but we requested 'NONE'.
  
−
Instead we use <tt>dpns-setacl</tt>. Use
+
There are other ways of using <tt>srm-set-permissions</tt>. Let's see what that gives:
−
  $ man dpns-setacl
+
  $ srm-set-permissions -type=REMOVE -group=RWX  $SRM/myfile
−
for a full manual page, as there are '''many''' options for this command.
+
Return code: SRM_INVALID_REQUEST
−
 
+
Explanation: Group 500 does not exist
−
For our example we wish to
+
No change. Next:
−
* remove the default <tt>group</tt> bits: <tt>g::0</tt>
+
$ srm-set-permissions -type=REMOVE -other=RWX  $SRM/myfile
−
* remove the mask (to make sure other groups do not inherit permissions): <tt>m:0</tt>
+
Ah, that command did work: the intention of this command was to remove the permissions <tt>RWX</tt> for the <tt>other</tt> group. Let's see what the permissions are now:
−
* remove the <tt>other</tt> bits: <tt>o::0</tt>
+
  $ srm-get-permissions $SRM/myfile
−
 
+
# file  : srm://srm-dteam.gridpp.rl.ac.uk/castor/ads.rl.ac.uk/test/dteam/disk0tape0/janjust/myfile
−
  dpns-setacl -m g::0,m:0,o::0 /dpm/nikhef.nl/home/pvier/janjust/myfile
+
# owner : dteam001
−
 
+
owner:dteam001:NONE
−
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.
+
user:dteam001:NONE
 +
group:dteam:NONE
 +
other:NONE
 +
Now '''ALL''' permissions are gone ?!?!?!?
 +
This just keeps getting better and better, doesn't it ;-) ?
  
 
= Verifying access control =
 
= Verifying access control =
  
 
As the original user:
 
As the original user:
−
  $ dpns-getacl /dpm/nikhef.nl/home/pvier/janjust/myfile
+
  $ srm-get-permissions $SRM/myfile
−
  # file: /dpm/nikhef.nl/home/pvier/janjust/myfile
+
  # file : srm://srm-dteam.gridpp.rl.ac.uk/castor/ads.rl.ac.uk/test/dteam/disk0tape0/janjust/myfile
−
  # owner: /O=dutchgrid/O=users/O=nikhef/CN=Jan Just Keijser
+
  # owner : dteam001
−
  # group: pvier
+
  owner:dteam001:NONE
−
  user::rw-
+
  user:dteam001:NONE
−
  group::---              #effective:---
+
  group:dteam:NONE
−
  group:pvier/Role=production:rwx        #effective:---
+
  other:NONE
−
  group:pvier/Role=lcgadmin:rwx          #effective:---
+
Let's try to read it:
−
  mask::---
+
  $ lcg-cp $SRM/myfile file://$PWD/blah
−
  other::---
+
globus_ftp_client: the server responded with an error
 +
  500 Command failed. : open error: Permission denied
 +
 +
  lcg_cp: Permission denied
 +
Well, at least the permissions are consistent with the <tt>lcg-cp</tt> command.
  
−
so this file should now be accessible only to the user.
+
Let's give access back to the owner:
 +
$ srm-set-permissions -type=ADD -owner=RWX  $SRM/myfile
 +
And try again:
 +
$ 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:NONE
 +
other:NONE
 +
 +
$ lcg-cp $SRM/myfile file://$PWD/blah
 +
$ ls -al blah
 +
-rw-r--r--  1 janjust datagrid 8508 Aug 20 16:49 blah
 +
so at least we can copy the file again.
  
 
Now if we switch to another VO:
 
Now if we switch to another VO:
−
  $ voms-proxy-init --voms vlemed
+
  $ voms-proxy-init --voms pvier
 
  Enter GRID pass phrase:
 
  Enter GRID pass phrase:
 
  Your identity: /O=dutchgrid/O=users/O=nikhef/CN=Jan Just Keijser
 
  Your identity: /O=dutchgrid/O=users/O=nikhef/CN=Jan Just Keijser
−
  Creating temporary proxy .......................................... Done
+
  Creating temporary proxy ........................................................ Done
−
  Contacting  voms.grid.sara.nl:30003 [/O=dutchgrid/O=hosts/OU=sara.nl/CN=voms.grid.sara.nl] "vlemed" Done
+
  Contacting  voms.grid.sara.nl:30000 [/O=dutchgrid/O=hosts/OU=sara.nl/CN=voms.grid.sara.nl] "pvier" Done
−
  Creating proxy ............................. Done
+
  Creating proxy ........................................................... Done
−
  Your proxy is valid until Thu Aug 6 23:45:56 2009
+
  Your proxy is valid until Fri Aug 21 05:18:15 2009
 
and then try to copy the file
 
and then try to copy the file
−
  $ srmcp -2 $SRM/myfile file://$PWD/blah
+
  $ lcg-cp $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
+
we get '''NO''' error message.  
−
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
+
Let's create a VO-less proxy and try again:
−
an SRMv1 protocol, even though we have added the SRMv2 port 8446 to the SRM URL.  
+
$ grid-proxy-init -old
 +
Your identity: /O=dutchgrid/O=users/O=nikhef/CN=Jan Just Keijser
 +
Enter GRID pass phrase for this identity:
 +
Creating proxy ....................................................... Done
 +
Your proxy is valid until: Fri Aug 21 05:22:13 2009
 +
 +
$ voms-proxy-info -all
 +
WARNING: Unable to verify signature! Server certificate possibly not installed.
 +
Error: VOMS extension not found!
 +
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  : 512 bits
 +
path      : /tmp/x509up_u7651
 +
timeleft  : 11:59:59
 +
 +
$ lcg-cp $SRM/myfile file://$PWD/blah
 +
And again, we get '''NO''' error message.  
  
−
If we ask another member of the <tt>pvier</tt> VO to retrieve the file we see:
+
Next we ask a colleague to try it as well and he also gets '''NO''' error message !!
−
 
 
−
[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.
+
Some investigation shows that the gridmap-file on the CASTOR nodes maps all users for a particular VO to a single userid
 +
<tt>dteam001</tt>. So even though the group permissions are now gone anybody who is mapped to this userid can read/write/delete
 +
my files.  
  
−
'''Note''' that we used '''-send_cksm=false''' when copying a local file to the SRM. If we do not specify this parameter we see
+
= Conclusion =
−
$ srmcp -2 file:///$PWD/myfile $SRM/myfile3
+
Access control in CASTOR is not very well implemented:
−
GridftpClient: Was not able to send checksum value:org.globus.ftp.exception.ServerException:  
+
* The <tt>srm-{get,set}-permissions</tt> commands do work but not in a comprehensible manner.
−
Server refused performing the request.
+
* The fact that multiple users, regardless of the VOMS-extensions in their proxies, are mapped to a single userid makes access control useless.
−
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.
 

Latest revision as of 16:01, 9 December 2009

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

Note #1 before using the srm* commands make sure that the SRM client is at least 2.1.0 as otherwise most, if not all, srm* commands will fail: 

$ srmping -version
Storage Resource Manager (SRM) Client version 2.1.0
Copyright (c) 2002-2008 Fermi National Accelerator Laborator

Note #2 The glite 3.2 UI up to version 3.2.4 contains an older (actually, too old !) version of the srm-client than the glite 3.1 UI !

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 CASTOR 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://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 /grid/pvier/janjust which was actually a mistake. However, the LFC allows me to write to this directory even though I used a dteam 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) 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. 

$ 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

Use 

srm-set-permissions -h

to get a list of options for this command. 

$ srm-set-permissions -type=CHANGE -group=NONE -other=NONE $SRM/myfile
Return code: SRM_INVALID_REQUEST
Explanation: Group 500 does not exist

Don't you just love these kind of error messages? Some experimentation shows that the -group=NONE part is wreaking havoc: 

$ srm-set-permissions -type=CHANGE -other=NONE  $SRM/myfile

returns no errors, but ... 

$ 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:RW
other:R             # <------------- !!!!!

it also did not do what we expected: the other permissions are still R but we requested 'NONE'.

There are other ways of using srm-set-permissions. Let's see what that gives: 

$ srm-set-permissions -type=REMOVE -group=RWX  $SRM/myfile
Return code: SRM_INVALID_REQUEST
Explanation: Group 500 does not exist

No change. Next: 

$ srm-set-permissions -type=REMOVE -other=RWX  $SRM/myfile

Ah, that command did work: the intention of this command was to remove the permissions RWX for the other group. Let's see what the permissions are now: 

$ 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:NONE
user:dteam001:NONE
group:dteam:NONE
other:NONE

Now ALL permissions are gone ?!?!?!? This just keeps getting better and better, doesn't it ;-) ?

Verifying access control

As the original user: 

$ 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:NONE
user:dteam001:NONE
group:dteam:NONE
other:NONE

Let's try to read it: 

$ lcg-cp $SRM/myfile file://$PWD/blah
globus_ftp_client: the server responded with an error
500 Command failed. : open error: Permission denied

lcg_cp: Permission denied

Well, at least the permissions are consistent with the lcg-cp command.

Let's give access back to the owner: 

$ srm-set-permissions -type=ADD -owner=RWX  $SRM/myfile

And try again: 

$ 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:NONE
other:NONE

$ lcg-cp $SRM/myfile file://$PWD/blah 
$ ls -al blah
-rw-r--r--  1 janjust datagrid 8508 Aug 20 16:49 blah

so at least we can copy the file again.

Now if we switch to another VO: 

$  voms-proxy-init --voms pvier
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:30000 [/O=dutchgrid/O=hosts/OU=sara.nl/CN=voms.grid.sara.nl] "pvier" Done
Creating proxy ........................................................... Done
Your proxy is valid until Fri Aug 21 05:18:15 2009

and then try to copy the file 

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

we get NO error message.

Let's create a VO-less proxy and try again: 

$ grid-proxy-init -old
Your identity: /O=dutchgrid/O=users/O=nikhef/CN=Jan Just Keijser
Enter GRID pass phrase for this identity:
Creating proxy ....................................................... Done
Your proxy is valid until: Fri Aug 21 05:22:13 2009

$ voms-proxy-info -all
WARNING: Unable to verify signature! Server certificate possibly not installed.
Error: VOMS extension not found!
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  : 512 bits
path      : /tmp/x509up_u7651
timeleft  : 11:59:59

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

And again, we get NO error message.

Next we ask a colleague to try it as well and he also gets NO error message !!

Some investigation shows that the gridmap-file on the CASTOR nodes maps all users for a particular VO to a single userid dteam001. So even though the group permissions are now gone anybody who is mapped to this userid can read/write/delete my files.

Conclusion

Access control in CASTOR is not very well implemented:

  • The srm-{get,set}-permissions commands do work but not in a comprehensible manner.
  • The fact that multiple users, regardless of the VOMS-extensions in their proxies, are mapped to a single userid makes access control useless.
Retrieved from "https://wiki.nikhef.nl/grid/index.php?title=Access_control_for_CASTOR_storage_elements&oldid=7227"