Access control for StoRM storage elements

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

Finding out how storage is organized

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 the current version of the lcg-infosites command does not use your grid proxy at all !

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

$ srmls -l srm://srm.grid.rug.nl/
SRMClientV2 : srmLs: try # 0 failed with error
SRMClientV2 : ; nested exception is:
        java.net.NoRouteToHostException: No route to host
SRMClientV2 : srmLs: try again

Ah, the SRM server is listening on a different port. Storm documentation suggests using port 8444:

$ srmls -l srm://srm.grid.rug.nl:8444/
srm client error:
java.lang.Exception: Return status:
 - Status code:  SRM_FAILURE
 - Explanation:  All requests failed

Progress, more or less...

By looking at a file that was previously stored on srm.grid.rug.nl (using lcg-lr) we guess that the directory structure starts with the VO:

$ srmls srm://srm.grid.rug.nl:8444/pvier/
 0 /pvier/
     0 /pvier/vletgenerated
     0 /pvier/generated

Indeed, we're at the VO level.

Creating your own directory in SRM-space

Before we copy a file to the dCache 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.grid.rug.nl:8444/pvier/janjust

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

SRM=srm://srm.grid.rug.nl:8444/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-storm-file file://$PWD/myfile
guid:1601bad4-c236-4f01-a4fb-54e12c7dc0a9

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 an 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
srm-get-permissions $SRM/myfile
Return code: SRM_NOT_SUPPORTED
Explanation: Not supported

permissions array is null

Uh-oh... it looks like StoRM does not support permissions or access control

Modifying the permissions

Not supported