Access control for the LFC

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 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

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


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
drwxrwxr-x  37 root     2025                      0 Aug 04 13:31 pvier
drwxrwxr-x  28 root     2031                      0 Aug 06 10:34 vlemed

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


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

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 -l lfn:/grid/pvier/janjust/myfile2 file://$PWD/myfile

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
group::rw-              #effective:rw-

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

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

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

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

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

$ lcg-gt srm:// gsiftp

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

$ globus-url-copy gsi \

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

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

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

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
group::---              #effective:---

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 [/O=dutchgrid/O=hosts/] "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

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

Eh??? It turns out to be another bug:

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

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

[tbalint] $ lcg-lr lfn:/grid/pvier/janjust/private/my-private-file
[LFC][lfc_getreplica][] /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.


Access control at the LFC level works, more or less:

  • it is possible to control access to a directory, not to a file
  • it must be noted that hiding access to an LFC entry does nothing with the access to the actual file/data. Once you understand the design this is logical, but new users might get confused by this.