> -----Original Message-----
> From: Testbed Support for GridPP member institutes [mailto:TB-
> [log in to unmask]] On Behalf Of Henry Nebrensky
>
> Both these activities are indeed still possible by using gridftp, but
> then at least you have the gridftp logs to provide a trail of who did
> what; with the NFS route you might not have more than a timestamp
> (group-writable files could have been modified by any pool user).
> The simplest solution might simply be to only mount the SE space
> read-only, but that's yet another thing that would have to be
published
> correctly (and then parsed by the user).
>
Surely the correct and simple solution to this (in principle - I'm not
aware
of any SRM implementation that does this) is to use a single pool
account
mapping for a given user[1] across a whole site, so both running jobs
and
storage access happen with the same mapped account. That way running
jobs
have the correct permissions to access a user's data even with direct
file://
access, you know exactly who created what without needing to log
everything,
and the SRM doesn't need to maintain it's own database of mappings and
permissions (DPM) or do amusing things with filesystem ACLs (SToRM).
Ewan
[1] Not actually per user, more like per DN+VO+Role, but the principle
stands.
|