Difference between revisions of "How to control access rights for LFC/SRM files"
(→dCache) |
|||
| (15 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | Storing files on the grid is one thing. Controlling access to these files is a different matter. | + | Storing files on the grid is one thing. Controlling access to these files is a different matter. These pages are the result of an ongoing investigation on how to control access rights for different storage systems (currently: dCache and DPM), as well as the way files are stored and accessed on the Local File Catalog (LFC). |
| − | + | '''SRM vs LFC''' | |
| − | + | Files which are stored on the grid are registered in at least one, but usually two places: | |
| + | * The back-end storage system. This is the place where the data actually resides. Most back-end storage systems can be accessed using the Storage Resource Manager (SRM) protocol. | ||
| + | * The Local File Catalog: this catalog is intended to provide users with an easier-to-use Logical File Name (LFN) , plus it allows for the use of replica's across different back-end storage systems. | ||
| + | The coupling between the back-end storage and the LFC is not very tight. It is possible to rename a file in the back-end storage system without the LFC knowing about it (resulting in the 'disappearance' of the file in the LFC). You can also delete a file in the LFC while keeping the file stored on the back-end storage system. In most cases this is called 'dark storage'. | ||
| − | + | Access rights between the back-end storage and the LFC are '''also not coupled''' : this means you can add or revoke access rights to a particular file or directory in the LFC , but if you do not also modify the access rights in the back-end storage then the file is still accessible !! This can be especially dangerous if a malicious user does not know anything about your LFC entries but if he '''does''' know the Transport URL (TURL) for a file then he might still be able to copy the file from the back-end storage using a plain <tt>globus-url-copy</tt> command (for gsiftp TURLs). | |
| − | + | A logical question that comes to mind is : '''Why''' are the back-end storage and the LFC not coupled? | |
| − | + | The reason they are not coupled is due to the distributed nature of the grid. User A can copy a file to a back-end storage system, while user B registers it in the LFC. Also, the LFC might be part of one administrative domain (e.g. grid.sara.nl) whereas the back-end storage is part of another (e.g. nikhef.nl). In 98% of the cases this will not be a problem and (theoretically) it would be possible to automatically synchronize the access rights between the back-end storage and the LFC, but it's the remaining 2% which prevent this coupling from happening automagically. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | Before we start: it is assumed that you already have generated a valid VOMS proxy prior to attempting any of these commands. It is also assumed that you have access rights to the storage systems used below. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | All of the sample output on these pages was generated using a GT2-style proxy for the Dutch VO <tt>pvier</tt>, unless noted otherwise. | |
| − | + | * [[Access control for dCache storage elements]] | |
| + | * [[Access control for DPM storage elements]] | ||
| + | * [[Access control for StoRM storage elements]] : '''Spoiler alert''': StoRM does not seem to support access control !!! | ||
| + | * [[Access control for CASTOR storage elements]] | ||
| + | * [[Access control for the LFC]] | ||
| − | + | This investigation was initiated by Tünde Bálint, a research student at Nikhef, in cooperation with Jan Just Keijser. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Latest revision as of 14:43, 20 August 2009
Storing files on the grid is one thing. Controlling access to these files is a different matter. These pages are the result of an ongoing investigation on how to control access rights for different storage systems (currently: dCache and DPM), as well as the way files are stored and accessed on the Local File Catalog (LFC).
SRM vs LFC
Files which are stored on the grid are registered in at least one, but usually two places:
- The back-end storage system. This is the place where the data actually resides. Most back-end storage systems can be accessed using the Storage Resource Manager (SRM) protocol.
- The Local File Catalog: this catalog is intended to provide users with an easier-to-use Logical File Name (LFN) , plus it allows for the use of replica's across different back-end storage systems.
The coupling between the back-end storage and the LFC is not very tight. It is possible to rename a file in the back-end storage system without the LFC knowing about it (resulting in the 'disappearance' of the file in the LFC). You can also delete a file in the LFC while keeping the file stored on the back-end storage system. In most cases this is called 'dark storage'.
Access rights between the back-end storage and the LFC are also not coupled : this means you can add or revoke access rights to a particular file or directory in the LFC , but if you do not also modify the access rights in the back-end storage then the file is still accessible !! This can be especially dangerous if a malicious user does not know anything about your LFC entries but if he does know the Transport URL (TURL) for a file then he might still be able to copy the file from the back-end storage using a plain globus-url-copy command (for gsiftp TURLs).
A logical question that comes to mind is : Why are the back-end storage and the LFC not coupled?
The reason they are not coupled is due to the distributed nature of the grid. User A can copy a file to a back-end storage system, while user B registers it in the LFC. Also, the LFC might be part of one administrative domain (e.g. grid.sara.nl) whereas the back-end storage is part of another (e.g. nikhef.nl). In 98% of the cases this will not be a problem and (theoretically) it would be possible to automatically synchronize the access rights between the back-end storage and the LFC, but it's the remaining 2% which prevent this coupling from happening automagically.
Before we start: it is assumed that you already have generated a valid VOMS proxy prior to attempting any of these commands. It is also assumed that you have access rights to the storage systems used below.
All of the sample output on these pages was generated using a GT2-style proxy for the Dutch VO pvier, unless noted otherwise.
- Access control for dCache storage elements
- Access control for DPM storage elements
- Access control for StoRM storage elements : Spoiler alert: StoRM does not seem to support access control !!!
- Access control for CASTOR storage elements
- Access control for the LFC
This investigation was initiated by Tünde Bálint, a research student at Nikhef, in cooperation with Jan Just Keijser.
