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

From PDP/Grid Wiki
Jump to navigationJump to search
 
(27 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
This page is part of an investigation on [[How to control access rights for LFC/SRM files]] .
 
This page is part of an investigation on [[How to control access rights for LFC/SRM files]] .
  
−
= Finding out how storage is organized =
+
= Finding out which storage systems are available =
  
 
To list the storage systems to which you have access use
 
To list the storage systems to which you have access use
Line 22: Line 22:
 
  771834491      620488567      n.a    gb-se-lumc.lumc.nl
 
  771834491      620488567      n.a    gb-se-lumc.lumc.nl
  
−
'''Note''' the current version of the <tt>lcg-infosites</tt> command does not use your grid proxy at all !
+
'''Note #1''' the current version of the <tt>lcg-infosites</tt> command does not use your grid proxy at all !
  
−
You can then use the <tt>srmls</tt> command to figure out how the storage is organized:
+
'''Note #2''' 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 #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 !
  
−
$ 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 <tt>srmLs</tt> command. The SRMv2 interface for
+
You can use the <tt>srmping</tt> 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 <tt>srmPing</tt> command. The SRMv2 interface for
 
DPM installations is on port 8446 by default.  
 
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 <tt>tbn18.nikhef.nl</tt> is a SRMv2.2 compliant storage system based on DPM.
 +
 +
= Finding out how storage is organized =
 +
 +
You can use the <tt>srmls</tt> command to figure out how the storage is organized:
 +
 
  $ srmls srm://tbn18.nikhef.nl:8446/
 
  $ srmls srm://tbn18.nikhef.nl:8446/
 
   0 //
 
   0 //
Line 75: Line 92:
  
 
We could also have copied the file to the SRM only, bypassing the LFC registration, using the command
 
We could also have copied the file to the SRM only, bypassing the LFC registration, using the command
−
  srmcp file://$PWD/myfile $SRM/my-dpm-file
+
  lcg-cp file://$PWD/myfile $SRM/myfile
−
but as we needed the LFC entry as well we used the (preferred) <tt>lcg-cr</tt> command.
+
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 =
 
= Looking at the permissions =
Line 86: Line 106:
 
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
−
  # file  : srm://srm.grid.sara.nl/pnfs/grid.sara.nl/data/pvier/janjust/myfile
+
  # file  : srm://tbn18.nikhef.nl:8446/dpm/nikhef.nl/home/pvier/janjust/myfile
−
  # owner : 18010
+
  # owner : /O=dutchgrid/O=users/O=nikhef/CN=Jan Just Keijser
−
  owner:18010:RW
+
  owner:/O=dutchgrid/O=users/O=nikhef/CN=Jan Just Keijser:RW
−
  user:18010:RW
+
  group:pvier:RWX
−
  group:1276:R
+
group:pvier/Role=production:RWX
 +
  group:pvier/Role=lcgadmin:RWX
 
  other:R
 
  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 <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:
−
  $ srm-get-permissions srm://srm.grid.sara.nl/pnfs/grid.sara.nl/data/pvier/ronstestdir3
+
  $ srm-get-permissions srm://tbn18.nikhef.nl:8446/dpm/nikhef.nl/home/vlemed/foo.txt 
−
  # file  : srm://srm.grid.sara.nl/pnfs/grid.sara.nl/data/pvier/ronstestdir3
+
  # file  : srm://tbn18.nikhef.nl:8446/dpm/nikhef.nl/home/vlemed/foo.txt
−
  # owner : 18010
+
  # owner : /O=dutchgrid/O=users/O=uva/OU=wins/CN=Tristan Glatard
−
  owner:18010:RWX
+
  owner:/O=dutchgrid/O=users/O=uva/OU=wins/CN=Tristan Glatard:RW
−
  user:18010:RWX
+
group:vlemed:RW
−
  group:1276:NONE
+
  group:vlemed/Role=production:RWX
−
  other:NONE
+
  group:vlemed/Role=lcgadmin:RWX
−
Wait a second... that file has '''exactly''' the same user (18010) and group (1276) !
+
  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
  
−
Now let's check a directory that was created using a different VOMS proxy, this time one for VO <tt>vlemed</tt>:
 
−
$ srm-get-permissions srm://srm.grid.sara.nl/pnfs/grid.sara.nl/data/vlemed/generated/2007-11-07
 
−
# file  : srm://srm.grid.sara.nl/pnfs/grid.sara.nl/data/vlemed/generated/2007-11-07
 
−
# owner : 18002
 
−
owner:18002:RWX
 
−
user:18002:RWX
 
−
group:1276:RX
 
−
other:RX
 
−
This time the user is different (18002) but the group is still 1276 !
 
 
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.
  
−
'''Note''': this limitation is due to the setup of the dCache storage system at SARA, where <tt>pnfs</tt> is used as
+
===Multiple group permissions===
−
the underlying file system.
+
Where did the multiple group permissions come from? When we do a
−
<tt>pnfs</tt> does not support user-level access control. An alternative is to use <tt>chimera</tt> as the underlying
+
voms-proxy-info -all
−
file system, which does support user-level ACLs, but this would require a migration of '''all''' data currently in
+
we get
−
dCache, as well as a (manual) re-synchronization between dCache and all LFCs that have entries pointing to dCache.
+
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 <tt>dpns-getacl</tt> 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 =
 
= Modifying the permissions =
Line 126: Line 206:
 
  srm-set-permissions -h
 
  srm-set-permissions -h
 
to get a list of options for this command.
 
to get a list of options for this command.
 +
 +
Let's remove all permissions for <tt>group</tt> and <tt>other</tt> on $SRM/myfile:
 
  $ srm-set-permissions -type=CHANGE -group=NONE -other=NONE $SRM/myfile
 
  $ srm-set-permissions -type=CHANGE -group=NONE -other=NONE $SRM/myfile
 
(this command does not return any output on success)
 
(this command does not return any output on success)
−
 
−
'''Note''' that we have set the group permissions to <NONE> . If we do not do this then users from other VOs can still read the file.
 
  
 
= Verifying access control =
 
= Verifying access control =
Line 135: Line 215:
 
As the original user:
 
As the original user:
 
  $ srm-get-permissions $SRM/myfile
 
  $ srm-get-permissions $SRM/myfile
−
  # file  : srm://srm.grid.sara.nl/pnfs/grid.sara.nl/data/pvier/janjust/myfile
+
  # file  : srm://tbn18.nikhef.nl:8446/dpm/nikhef.nl/home/pvier/janjust/myfile
−
  # owner : 18010
+
  # owner : /O=dutchgrid/O=users/O=nikhef/CN=Jan Just Keijser
−
  owner:18010:RW
+
  owner:/O=dutchgrid/O=users/O=nikhef/CN=Jan Just Keijser:RW
−
  user:18010:RW
+
  group:pvier:NONE
−
  group:1276:NONE
+
group:pvier/Role=production:RWX
 +
  group:pvier/Role=lcgadmin:RWX
 
  other:NONE
 
  other:NONE
 +
 +
Eh? It seems that the permissions were removed only for the first group.
 +
We need the <tt>dpns-setacl</tt> 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:
 
Now if we switch to another VO:
−
 
 
  $ voms-proxy-init --voms vlemed
 
  $ voms-proxy-init --voms vlemed
 
  Enter GRID pass phrase:
 
  Enter GRID pass phrase:
Line 152: Line 240:
 
  Your proxy is valid until Thu Aug  6 23:45:56 2009
 
  Your proxy is valid until Thu Aug  6 23:45:56 2009
 
and then try to copy the file
 
and then try to copy the file
−
  $ srmcp $SRM/myfile file://$PWD/blah
+
  $ srmcp -2 $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 :  
+
we get '''NO''' error message: DPM behaves much more like regular UNIX. The file is still owned by the original
−
  created RequestFileStatus#-2083337326 failed with error:[ at Thu Aug 06 11:46:36 CEST 2009 state Failed :  
+
user (/CN=Jan Just Keijser) and thus that user is still allowed to retrieve the file, even though the voms proxy
−
  user AR:3209444168817257963  vlemed /O=dutchgrid/O=users/O=nikhef/CN=Jan Just Keijser 18002
+
belongs to another VO.
−
  read-write 0 / / < 1 groupLists :   GL:/vlemed 1 groups : [1276,]; >cannot read 00190000000000000018C718]
+
 
 +
'''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
 
   
 
   
−
  Thu Aug 06 11:46:41 CEST 2009: java.io.IOException: rs.state = Failed rs.error =  at Thu Aug 06 11:46:36
+
  $ dpns-getacl /dpm/nikhef.nl/home/pvier/janjust/myfile3
−
  CEST 2009 state Pending : created
+
  # file: /dpm/nikhef.nl/home/pvier/janjust/myfile3
−
  RequestFileStatus#-2083337326 failed with error:[  at Thu Aug 06 11:46:36 CEST 2009 state Failed :
+
  # owner: /O=dutchgrid/O=users/O=nikhef/CN=Jan Just Keijser
−
user AR:3209444168817257963 vlemed /O=dutchgrid/O=users/O=nikhef/CN=Jan Just Keijser 18002
+
  # group: pvier
−
  read-write 0 / / < 1 groupLists :   GL:/vlemed 1 groups : [1276,]; >cannot read 00190000000000000018C718]
+
user::rw-
−
   
+
group::rw-              #effective:rw-
−
  srm copy of at least one file failed or not completed
+
  mask::rw-
 +
  other::r--
 +
 
 +
And we see that there is only a single <tt>group</tt> entry.
  
−
We can no longer access the file: success!
+
'''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.
  
−
'''Notes'''
+
= Conclusion =
−
* it currently is '''not''' possible with dCache PNFS to restrict access to a file for your fellow VO-members.
+
Access control in DPM is working quite well, with some notes:
−
* the dCache server has mapped the voms proxy to a different user (18002), which causes the <tt>srmcp</tt> request to fail. Thus dCache user+group mappings are slightly different from UNIX user+group mappings:
+
* If the DPM server is older than v1.7.3 then the <tt>srm-{get,set}-permissions</tt> do not work. As a work-around the <tt>dpns-{get,set}acl</tt> can be used
−
** user+group1 = dcache_user1
+
* 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 <tt>dpns-{get,set}acl</tt> commands should be used.
−
** 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.
 

Latest revision as of 09:50, 4 November 2010

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:

  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
# 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.
Retrieved from "https://wiki.nikhef.nl/grid/index.php?title=Access_control_for_DPM_storage_elements&oldid=7188"