Access control for DPM 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 .

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 use the srmls command to figure out how the storage is organized:

$ srmls srm://tbn18.nikhef.nl
SRMClientV2 : srmLs: try # 0 failed with error
SRMClientV2 : Method 'ns1:srmLs' not implemented: method name or namespace not recognized
SRMClientV2 : srmLs: try again

Ah... this is a SRMv1 interface, which does not support the srmLs command. The SRMv2 interface for DPM installations is on port 8446 by default.

$ 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

srmcp file://$PWD/myfile $SRM/myfile

but as we needed the LFC entry as well we used the (preferred) lcg-cr command.

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.

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
  • remove the mask (to make sure other groups do not inherit permissions)
  • remove the otherbits
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:

$ srm-get-permissions $SRM/myfile
# file  : srm://srm.grid.sara.nl/pnfs/grid.sara.nl/data/pvier/janjust/myfile
# owner : 18010
owner:18010:RW
user:18010:RW
group:1276:NONE
other:NONE

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 $SRM/myfile file://$PWD/blah
Thu Aug 06 11:46:41 CEST 2009: rs.state = Failed rs.error =  at Thu Aug 06 11:46:36 CEST 2009 state Pending : 
created RequestFileStatus#-2083337326 failed with error:[  at Thu Aug 06 11:46:36 CEST 2009 state Failed : 
user AR:3209444168817257963   vlemed /O=dutchgrid/O=users/O=nikhef/CN=Jan Just Keijser 18002 
read-write 0 / / < 1 groupLists :   GL:/vlemed 1 groups : [1276,]; >cannot read 00190000000000000018C718]

Thu Aug 06 11:46:41 CEST 2009: java.io.IOException: rs.state = Failed rs.error =  at Thu Aug 06 11:46:36 
CEST 2009 state Pending : created
RequestFileStatus#-2083337326 failed with error:[  at Thu Aug 06 11:46:36 CEST 2009 state Failed : 
user AR:3209444168817257963 vlemed /O=dutchgrid/O=users/O=nikhef/CN=Jan Just Keijser 18002
read-write 0 / / < 1 groupLists :   GL:/vlemed 1 groups : [1276,]; >cannot read 00190000000000000018C718]

srm copy of at least one file failed or not completed

We can no longer access the file: success!

Notes

  • it currently is not possible with dCache PNFS to restrict access to a file for your fellow VO-members.
  • the dCache server has mapped the voms proxy to a different user (18002), which causes the srmcp request to fail. Thus dCache user+group mappings are slightly different from UNIX user+group mappings:
    • user+group1 = dcache_user1
    • user+group2 = dcache_user2

whereas on a regular UNIX filesystem you can always access a file that is owned by you, regardless of the groupid of the file.