Access control for DPM storage elements
This page is part of an investigation on How to control access rights for LFC/SRM files .
Finding out which storage systems are available
To list the storage systems to which you have access use
lcg-infosites --vo <YOUR-VO> se
which results in
Avail Space(Kb) Used Space(Kb) Type SEs ---------------------------------------------------------- 12078 108 n.a srm.grid.rug.nl 12078 108 n.a srm.grid.rug.nl 730582644 681194097 n.a gb-se-amc.amc.nl 8226695519985 23304480014 n.a srm.grid.sara.nl 605355546 806421195 n.a gb-se-nki.els.sara.nl 6575746866 20920246 n.a carme.htc.biggrid.nl 152913518 115521938 n.a se.grid.rug.nl 248345185 1166074827 n.a gb-se-ams.els.sara.nl 355230761 1056545980 n.a gb-se-uu.science.uu.nl 1266740857 145035883 n.a gb-se-wur.els.sara.nl 337812899 1076607113 n.a gb-se-kun.els.sara.nl 2195706454 3048365 n.a tbn18.nikhef.nl 771834491 620488567 n.a gb-se-lumc.lumc.nl
Note #1 the current version of the lcg-infosites command does not use your grid proxy at all !
Note #2 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 #3 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://tbn18.nikhef.nl SRMClientV2 : srmPing: try # 0 failed with error SRMClientV2 : Method 'ns1:srmPing' not implemented: method name or namespace not recognized SRMClientV2 : srmPing: try again
Ah... this is a SRMv1 interface, which does not support the srmPing command. The SRMv2 interface for DPM installations is on port 8446 by default.
$ srmping -2 srm://tbn18.nikhef.nl:8446 VersionInfo : v2.2 backend_type:DPM backend_version:1.7.4-7
So host tbn18.nikhef.nl is a SRMv2.2 compliant storage system based on DPM.
Finding out how storage is organized
You can use the srmls command to figure out how the storage is organized:
$ srmls srm://tbn18.nikhef.nl:8446/
0 //
0 //dpm/
Note the extra slash ('/') at the end of the command!
So yes, we are talking to a DPM server. Subsequent srmls commands then give us:
$ srmls srm://tbn18.nikhef.nl:8446/dpm
0 /dpm/
0 /dpm/nikhef.nl/
$ srmls srm://tbn18.nikhef.nl:8446/dpm/nikhef.nl
0 /dpm/nikhef.nl/
0 /dpm/nikhef.nl/home/
$ srmls srm://tbn18.nikhef.nl:8446/dpm/nikhef.nl/home
0 /dpm/nikhef.nl/home/
[SNIP]
0 /dpm/nikhef.nl/home/pvier/
0 /dpm/nikhef.nl/home/vlemed/
[SNIP]
Hey, we are at the VO level now. Here I've listed the two VOs which will be used throughout this page.
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:
- 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.
First we try the "standard" srm-get-permissions command:
$ srm-get-permissions $SRM/myfile # file : srm://tbn18.nikhef.nl:8446/dpm/nikhef.nl/home/pvier/janjust/myfile # owner : /O=dutchgrid/O=users/O=nikhef/CN=Jan Just Keijser owner:/O=dutchgrid/O=users/O=nikhef/CN=Jan Just Keijser:RW group:pvier:RWX group:pvier/Role=production:RWX group:pvier/Role=lcgadmin:RWX other:R
If instead you get
$ srm-get-permissions $SRM/myfile srm client error: java.lang.NullPointerException
then you've been bitten by bug https://gus.fzk.de/ws/ticket_info.php?ticket=50779. The DPM needs to be upgraded to v1.7.4 or higher in order to get rid of this message.
There is a second 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:
$ srm-get-permissions srm://tbn18.nikhef.nl:8446/dpm/nikhef.nl/home/vlemed/foo.txt # file : srm://tbn18.nikhef.nl:8446/dpm/nikhef.nl/home/vlemed/foo.txt # owner : /O=dutchgrid/O=users/O=uva/OU=wins/CN=Tristan Glatard owner:/O=dutchgrid/O=users/O=uva/OU=wins/CN=Tristan Glatard:RW group:vlemed:RW group:vlemed/Role=production:RWX group:vlemed/Role=lcgadmin:RWX 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
Note: the default permissions are shown only when the dpns-getacl command is used.
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
Use
srm-set-permissions -h
to get a list of options for this command.
Let's remove all permissions for group and other on $SRM/myfile:
$ srm-set-permissions -type=CHANGE -group=NONE -other=NONE $SRM/myfile
(this command does not return any output on success)
Verifying access control
As the original user:
$ srm-get-permissions $SRM/myfile # file : srm://tbn18.nikhef.nl:8446/dpm/nikhef.nl/home/pvier/janjust/myfile # owner : /O=dutchgrid/O=users/O=nikhef/CN=Jan Just Keijser owner:/O=dutchgrid/O=users/O=nikhef/CN=Jan Just Keijser:RW group:pvier:NONE group:pvier/Role=production:RWX group:pvier/Role=lcgadmin:RWX other:NONE
Eh? It seems that the permissions were removed only for the first group. We need the dpns-setacl command to remove the other permissions. The following commands will remove the permissions for other groups:
$ dpns-setacl -d g:pvier/Role=production /dpm/nikhef.nl/home/pvier/janjust/myfile $ dpns-setacl -d g:pvier/Role=lcgadmin /dpm/nikhef.nl/home/pvier/janjust/myfile
So now this file should 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.
Conclusion
Access control in DPM is working quite well, with some notes:
- If the DPM server is older than v1.7.3 then the srm-{get,set}-permissions do not work. As a work-around the dpns-{get,set}acl can be used
- access control can be done at a very fine grained level: it is possible to protect a file from other VOs, from other groups within a VO and even from a single user from within a VO. For this the dpns-{get,set}acl commands should be used.
