home directories
- does users access their EOS home area using grid protocols (e.g. root://eosuser.cern.ch//eos/user/[l]/[login])?
- yes (Maarten mentioned CMS?)
- do we expect this area should be accessible with grid protocols using tokens?
- yes, but first we have to solve grid workflows
- P.V. current profile and CERN EOS namespace organization is not compatible with token access with capabilities
- we can't set basepath for multiple issuers to /eos/user
- multiple experiments (at least VO / IAM Admins) would have full access to the data of any CERN user
- description of
storage.read:/home in the profile is not really clear to me
storage.create issues
- WLCG JWT profile storage.create definition: Upload data. This includes renaming files if the destination file does not already exist...
- what does this mean in case we don't use file level token granularity, e.g. for
storage.create:/atlasdatadisk/- this token can be used to make a mess in the namespace (rename all files in
/atlasdatadisk/) - rename
/atlasdatadisk/mc23_13p6TeV to /atlasdatadisk/RANDOM_STRING directories(?) - rename
/atlasdatadisk/mc23_13p6TeV/filename to /atlasdatadisk/DIFFERENT_RANDOM_STRING(?)- it is not completely clear from profile what exactly renaming mean
- might be a bit more tricky for object storage where directories are a bit artificial construct
- still much better situation than with X.509 - impossible to destroy data
- how can we prevent abuse of this "renaming" functionality
- always use tokens with file level access granularity (IAM performance)?
- ALICE use file level token granularity, but they don't use IAM for file transfers
- cleanest solution with our current WLCG JWT profile
- this would mean for ATLAS ~ 2.5M storage.create tokens per day in average (~ 30 tokens per second)
- get rid of "rename" from WLCG JWT profile and storage implementations?
- Rucio can be configured not to use different name (with
.rucio.upload suffix) during upload
- atomic "PUT+CHECKSUM+RENAME" operation (rename after successful transfer)?
- recovering from damage caused by abusing too wide renaming allowed with e.g.
storage.create:/atlasdatadisk/- for distributed storage management we have all metadata also e.g. in Rucio
- with (non-negligible effort) filesize + checksum could be used to recover original filename
FTS tokens design - token validation
- we should try to follow design document and ask IAM for all tokens that will be used in FTS transfers
- validate that IAM provides expected functionality, e.g. token exchange configuration