Difference between revisions of "Access control for the LFC"
From PDP/Grid Wiki
Jump to navigationJump to searchm (→Conclusion) |
|||
| (12 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]] . | ||
| + | |||
== Finding out how the Local File Catalog is organized == | == 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 <tt>lcg-infosites</tt> 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 <tt>lfc-ls</tt> 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 = | = 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 <tt>lcg-cr</tt> command. | ||
= Looking at the permissions = | = Looking at the permissions = | ||
| − | + | Use the <tt>lfc-getacl</tt> 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 <tt>lcg-l?</tt> 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 <tt>globus-url-copy</tt> 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 <tt>lcg-cr</tt> command shows that the file was placed in a <tt>generated</tt> 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 <tt>lcg-cr</tt> command. | ||
= Modifying the permissions = | = 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 <tt>dpns-setacl</tt> command. | ||
= Verifying access control = | = 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 <tt>pvier</tt> 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 <tt>lfc-setacl</tt> 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 <tt>pvier</tt> VO: | ||
| + | [tbalint] $ 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. | ||
| + | |||
| + | = Conclusion = | ||
| + | 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. | ||
Latest revision as of 15:38, 20 August 2009
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:
[tbalint] $ 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.
Conclusion
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.
