Security Model Discussion

• we need to figure out what it is!
• has implications on GFAL/glite-IO
• implications / expectations on SRM implementations

Discussion Material

Elements of the Game:

• X509 Certs and VOMS proxies
• MyProxy and renewal of proxies
• Delegation and its usage, see also FTSDelegationMyProxy
• ACLs and its storage (catalog and SRM)
• File Names (logical, GUID, SURL, TURL)

Meeting Notes (Akos and Peter)

SRM v2 and ACL support: have the component on the lowest possible layer exert access control

According to J-P Castor and dCache will support SRMv2 by March 2006 (DPM already does), so we shall make use of this, pushing down the authorization into the SE. J-P and Peter would follow up in the SRM group that everyone implements the same semantics.

• This decision has one implication on the component set: gLite I/O would not be needed, since authorization would be enforced in the SE.
• client tools need to be migrated to SRMv2, ie. SRMv2 enabled. they should be resilient and be able to talk to old SRMv1 servers as well. currently we have many srm clients, maybe having a single one that does it all would help.

There is a tricky use case with POSIX authorization semantics vs replication, if it is done with the user's privileges. To solve this issue J-P suggested introducing the 'replicator' role for FTS (or any functional equivalent). A service with this role would be able to copy files and directories from one SE to the other, preserving all permissions (like 'cp -p' does for 'root'), within the VO's scope.

• This solution has two implications: The new functionality has to be implemented in all SEs (SRMv2 probably); FTS no longer needs user proxies for replication, although we shall think about the semantics of what a normal user would be allowed to do!

A side issue here is to have only one implementation of the secure rfio protocol between DPM and Castor2, which needs some coordination effort.

Discussion Preparation : Use Cases

There are a few use cases that we should keep in mind, which we have to describe and work through how they will be addressed in the security model we decide on.

The most obvious ones are

File Upload

• A user wants to bring a file into the grid using a client
• The client may be on the WN or on a UI
• The file is new. What are the steps taken, how will the data be protected?

File Download

• A user wants to place a file on a target system outside the grid (remote ftp server, disk, etc)
• How is this achieved if the data is 'local' or if it is 'remote'

File Transfer from one SE to another SE without catalog interaction

• This is the FTS use case

File Transfer from one SE to another SE including catalog update

• This is the FPS use case

File Access from WN : checking complete file out for reading

• An executable in a job wants to access a given file from the WN.
• In order to do so it wants to get a local copy

File Access from WN : Partial file access

• An executalbe in a job wants to read just a few bytes off the file
• xrootd for experiments?
• what else for other applications?

Discussion Notes 10.11.05

SE: has a backend, an SRM interface, a gsiftp interface, a native IO interface

• backend supports ACLs natively
• SRM and gsiftp are 'superusers' of the backend and have chown authority

SRM v1 has no ACL support SRM v2 has posix ACLs

Use Case 1: File Upload

• putting a file is done by calling SRM, then either gsiftp or IO
• checking of ACLs is done in the backend and will fail if not properly set

Basically no problem today if it is possible to

1. Create DIRs on the SFN. covered by v2, gridftp even rfio

1. ACL setting?
   • on DPM there is a method to set the ACLs explicitly
   • Castor will merge this code and do the same thing

Q: where is the mapping of the user? ie what is the content of CN_setacl

A: the server side does the mapping but the client asks the server for the mapping and passes it back. CN_setacl contains numbers only.

first there is a mapping call and then the setacl. there is a caching of this information though.

Q: which interface exposes this setacl interface?

A: SRM v2 has setpermission with posix semantics there is a limitation though - you can have a list of users but not a list of groups. - is there a difference? just principals are needed... - j-p will check.

UC2 file get

works the same way as put for authorized data

UC3 SE to SE copy

srmCopy push mode

This requires delegation.

Calling the SRM to copy a file from it to a remote site a) if the directories of the target are there, everything works b) if the target dirs are not there, there are two options:

• create the target dirs
• fail (preferred)

Q: what is that the user expects? A: probably to just have it ..

Q: check existence, create dir? A: through SRMv2, or also gridftp

Q: are gridftp and SRM interchangeable for NS operations A: RAL is the exception where the gridftp and SRM talk to a different thing..

Q: should srmcopy also copy the ACLs to the target? A: no.. should not be but there is 'cp -p' yes but then you need the proper permissions on the target

problems:

• SRMv2 has a checkpermission but no explicit 'getpermission'! so if you want to copy the permissions from site A to site B there is no way to query what is there on site A using SRMv2 or gridftp. This is certainly something to have in an SRM2.2...
• For SRMv2 there is the detailed 'ls' call which will give you back all permissions for each entry (if it could be forced to give back only one, that would help)
• we don't really need SRMcopy in the first place.. it's been invented because dCache has internals that require it. it would be easier to convince dCache to change than for everyone to support SRMcopy..
• getting the directory entries with SRMv2 'ls' is not possible. the level '0' is for the current level. agree on '-1'?

srmCopy pull mode

Calling srm copy on the target to fetch the file locally.

• does not copy the ACL

3rd party gridftp

• does not copy the ACL

In all cases the problem is getting the original permission of the source SURL, since SRMv2 srmSetPermission() would allow us to set the permissions properly on the target. SRMv2 srmLs() could be used to get the permissions, however we should convince SRM vendors to have the (numOfLevels == -1) case implemented, when srmLs() would be equivalent of a simple stat() call.

Q: do you need delegation? discussion:

• no, because you have control channels to both servers
• yes..? need to check
• don't need delegation except for srm-cp, for gridftp maybe only for data channel auth

Still, the pure 'copy' use case can be satisfied as copy semantics are such that the permissions may change between copies.

Replication use case

The difference to a copy is exactly that the permissions are synchronized across copies.

• Maybe introduce a VOMS role to be able to replicate?
• service that performs replication has to have superuser permissions?
• Just a VOMS role/DNs that can be configured to actually set permissions on others, then you don't need a service

Problem: if a person adds ACL to write for another person in some subdirectory, that other person will not be able to do the copy since the parent tree permissions cannot be propagated by that user.

• can give a privilege (ACL) to a VOADMIN role, which can be given to the FTS, who can then fix this problem on the users's behalf.
• simply fail (preferred, see below why it is still OK)

Having ACLs in storage elements and the semantic on new entries that the parent directory's permissions are inherited would allow experiments to add a VOADMIN role to the VO's toplevel directory entry with full privileges. Starting from this, every file and directory under this tree would inherit this ACL entry, which means that someone with VOADMIN role would be able to do any modifications, i.e. fix permissions.

In this case, the user running a job in FTS could have a VOADMIN role, which would enable FTS to copy over permissions along with the data to the target SE.

Ownership Change

srmReassignToUser() is a problematic call, practically no SRM vendors have implemented it.

One could give it a new meaning, by introducing a superuser role, which would be allowed to reassign file or directory ownership without the target user's consent. Of course this should only be allowed inside the VO's directory tree and only for a VO member with a special role assigned by VOMS.

This semantic would allow that after replication one could also replicate the file ownership information, which might be important for accounting or quota issues.

After discussing it, it turned out not to be an important item to do.

Deletion

Having large directories with many files, it might be desired that only the owner could delete a file. However, according to the Posix semantics everyone, who has write permission on the directory, could delete a file. SRMv2 has only 'read', 'write' and 'execute' permissions defined.

There are two possible solutions:

• Introducing a 'delete' permission bit, which would be added to the ACL of each file. This is a deviation from the Posix semantics, and might be problematic with some vendors.
• Introducing the 'sticky' bit on directories (i.e. /tmp). This would be only a small extension on the SRMv2.1 specification and would match with most vendors.

-- PeterKunszt - 08 Nov 2005 -- AkosFrohner - 10 Nov 2005