Access control for the LFC

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

Finding out how the Local File Catalog is organized

To list the Local File Catalog for a particular VO use

 lcg-infosites --vo <YOUR-VO> lfc

which results in

lfc.grid.sara.nl

Note the current version of the lcg-infosites command does not use your grid proxy at all !

Set the environment variable LFC_HOST to point this host

export LFC_HOST=lfc.grid.sara.nl

You can then use the lfc-ls command to figure out how the LFC is organized:

$ lfc-ls -l /
drwxr-xr-x  31 root     root                      0 Feb 15  2007 grid

$ lfc-ls -l /grid
[SNIP]
drwxrwxr-x  37 root     2025                      0 Aug 04 13:31 pvier
drwxrwxr-x  28 root     2031                      0 Aug 06 10:34 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 LFC-space

Before we register a file in the LFC we first create our own directory.

lfc-mkdir /grid/pvier/janjust

Copying and registering your file

In another part of this investigation we created an SRM directory on a DPM server. 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

For more details, see Access control for DPM storage elements.

Next we will copy a file to an SRM directory we created earlier 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.

And we also copy a file to SRM and register it in the LFC without specifying a directory:

$ lcg-cr -d tbn18.nikhef.nl -l lfn:/grid/pvier/janjust/myfile2 file://$PWD/myfile
guid:fa4a182b-49f9-4989-a549-f01ab6e252f9

In this case a directory is generated automatically by the lcg-cr command.

Looking at the permissions

Use the lfc-getacl command to list the current permissions (ACLs) for an LFC entry:

$ lfc-getacl /grid/pvier/janjust/my-dpm-file
# file: /grid/pvier/janjust/my-dpm-file
# owner: /O=dutchgrid/O=users/O=nikhef/CN=Jan Just Keijser
# group: pvier
user::rw-
group::rw-              #effective:rw-
other::r--

And there is a whole list of lcg-l? commands as well:

$ lcg-la lfn:/grid/pvier/janjust/my-dpm-file
lfn:/grid/pvier/janjust/my-dpm-file

$ lcg-lg lfn:/grid/pvier/janjust/my-dpm-file
guid:bbdad839-b2d1-46f6-95ab-5b6561f7e72f

$ lcg-lr lfn:/grid/pvier/janjust/my-dpm-file
srm://tbn18.nikhef.nl/dpm/nikhef.nl/home/pvier/janjust/myfile

We can use the output of the last command to get a TURL for this file:

$ lcg-gt srm://tbn18.nikhef.nl/dpm/nikhef.nl/home/pvier/janjust/myfile gsiftp
gsiftp://hooivork.nikhef.nl/hooivork.nikhef.nl:/export/data/ncf/pvier/2009-08-06/myfile.15536824.0

which we can then plug into globus-url-copy to retrieve it:

$ globus-url-copy gsiftp://hooivork.nikhef.nl/hooivork.nikhef.nl:/export/data/ncf/pvier/2009-08-06/myfile.15536824.0 \
    file:///$PWD/blah5

LFC entries with automatic SRM filenames

Similarly, for the LFC entry with an automatically generated SRM filename we get:

$ lcg-la lfn:/grid/pvier/janjust/myfile2
lfn:/grid/pvier/janjust/myfile2

$ lcg-lg lfn:/grid/pvier/janjust/myfile2
guid:fa4a182b-49f9-4989-a549-f01ab6e252f9

$ lcg-lr lfn:/grid/pvier/janjust/myfile2
srm://tbn18.nikhef.nl/dpm/nikhef.nl/home/pvier/generated/2009-08-06/file055356a7-1973-4efe-b6a7-b72e3a6417a9

The SURL returned by the lcg-cr command shows that the file was placed in a generated directory. Individual users of a VO generally will not have the rights to change the ACLs on this directory. This is one of the main reasons to explictly specify a directory when copyregistering a file using the lcg-cr command.

Modifying the permissions

lfc-setacl -m g::0,o::0 /grid/pvier/janjust/my-dpm-file

Note that the syntax of this command is very similar to that of the dpns-setacl command.

Verifying access control

As the original user:

$ lfc-getacl /grid/pvier/janjust/my-dpm-file
# file: /grid/pvier/janjust/my-dpm-file
# owner: /O=dutchgrid/O=users/O=nikhef/CN=Jan Just Keijser
# group: pvier
user::rw-
group::---              #effective:---
other::---

so this file should now be accessible only to the user at the LFC-level.

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 access the LFC entry, e.g. to get the SRM endpoint we get

$ lcg-lr lfn:/grid/pvier/janjust/my-dpm-file
srm://tbn18.nikhef.nl/dpm/nikhef.nl/home/pvier/janjust/myfile

we get NO error message: the LFC behaves pretty much like regular UNIX. The LFC entry is still owned by the original user (/CN=Jan Just Keijser) and thus that user is still allowed to manipulate that entry, even though the voms proxy belongs to another VO.

If we ask another member of the pvier VO to retrieve the file we see:

[tbalint] $ lcg-lr lfn:/grid/pvier/janjust/my-dpm-file
srm://tbn18.nikhef.nl/dpm/nikhef.nl/home/pvier/janjust/myfile

Eh??? It turns out to be another bug: https://gus.fzk.de/ws/ticket_info.php?ticket=50768

Modifying directory permissions

It turns out that the lfc-setacl command does work on directories:

lfc-mkdir /grid/pvier/janjust/private
lfc-setacl -m g::0,o::0 /grid/pvier/janjust/private
lcg-cr -d $SRM/myfile4 -l lfn:/grid/pvier/janjust/private/my-private-file file://$PWD/myfile
guid:98723879-d45c-40ca-9676-ca80738579d1

Now if we again ask another member of the pvier VO:

$ lcg-lr lfn:/grid/pvier/janjust/private/my-private-file
[LFC][lfc_getreplica][] lfc.grid.sara.nl: /grid/pvier/janjust/private/my-private-file: Permission denied
lcg_lr: Permission denied

we observe that access to the LFC entry is now indeed denied.