True, and that's mostly a toolset integration issue I think (you'd
hope that the SEMsg stuff would also allow you to propagate ACLs to
SEs from LFCs, as well as the rest of the consistency it maintains,
but I am not sure it does).
Sam
On 5 October 2013 10:45, Christopher J. Walker <[log in to unmask]> wrote:
> What I was more concerned about was who can read/write/delete data where.
>
> Webdav will make access easier, but may therefore make mistakes easier.
>
> Chris
>
>
> On 03/10/13 16:26, Sam Skipsey wrote:
>>
>> I would tend to agree with Ewan: the data management tools aren't really
>> designed to do this level of blinding at the moment (at least with the
>> level of certainty that snoplus seem to require - which is higher than
>> Amazon provide on S3 by default(!) ).
>>
>> Sam
>>
>>
>> On 3 October 2013 14:21, Ewan MacMahon <[log in to unmask]
>> <mailto:[log in to unmask]>> wrote:
>>
>> > -----Original Message-----
>> > From: GRIDPP2: Deployment and support of SRM and local storage
>> management
>> > [mailto:[log in to unmask]
>> <mailto:[log in to unmask]>] On Behalf Of Christopher J.
>> Walker
>> >
>> > Dear GridPP storage - we ought to think about the advice we give
>> here
>> > (unless we already have some).
>> >
>>
>> I've been thinking about this a bit, and I've mostly decided that it's
>> just too fiddly and uncertain to try to do this this way. Whatever the
>> state of SRM and LFC implementations now may be, we're likely to have
>> a future that doesn't have SRM, and may well have non-LFC type
>> catalogues.
>>
>> If someone really wants to make sure that some data is both
>> inaccessible,
>> but also clearly and convincingly so, they should just encrypt it and
>> be
>> done with it.
>>
>> Ewan
>>
>>
>
|