Dear GridPP storage - we ought to think about the advice we give here
(unless we already have some).

Chris


On 01/10/13 15:24, Matthew Mottram wrote:
> Er, panic over! Sorry about that! Having checked, I realised that I
> was being stupid - it's only the original uploader who is able to delete
> data regardless of proxy role; otherwise data uploaded by a user with a
> specific role (admin/production etc) can only be deleted by other users
> with an equivalent role in their proxy.
>
> I've also tested blinding data using lfc-setacl and lfc-chmod; both seem
> fine for setting access at the LFC level (i.e. using lcg-cp to copy an
> LFN or GUID), but if the user is able to find the underlying storage URL
> then they will still be able to read the data. The extent to which we
> need to hide blinded data should probably be discussed; we can set
> permissions on the storage URL if needed but srm-set-permissions (the
> tool for this) is awkward to use, it may be that Chris/other experts can
> suggest a better method,
>
> Cheers,
> Matt
>
> On 1 Oct 2013, at 11:32, Matthew Mottram wrote:
>
>> Looking at this a little more closely:
>>
>> lfc-getacl
>> /grid/snoplus.snolab.ca/production_testing/blinding_test/se03.esc.qmul.ac.uk/
>> # file:
>> /grid/snoplus.snolab.ca/production_testing/blinding_test/se03.esc.qmul.ac.uk/
>> # owner: /C=CA/O=Grid/OU=westgrid.ca/CN=Matthew Mottram tad-692
>> # group: snoplus.snolab.ca/Role=production
>> <http://snoplus.snolab.ca/Role=production>
>> user::rwx
>> group::rwx#effective:rwx
>> other::r-x
>>
>> So, it's possible that the files are writeable by users with
>> production roles in their proxy and also by me with any proxy role. I
>> have two grid certificates so can test this with different certs, but
>> i'd be good if we could get someone else (*without a production role*)
>> to test the deletion of these files.
>>
>> Cheers,
>> Matt
>>
>> On 1 Oct 2013, at 11:21, Matthew Mottram wrote:
>>
>>> Hi Chris,
>>>
>>> I've just run some tests to check the permissions on data that is
>>> uploaded to grid storage with production proxies. I found that on
>>> every SE that we can access, data can be deleted with a regular proxy
>>> via lcg-del -a. This is pretty worrying, do production users really
>>> have to upload, then set permissions on each file? I'm sure that I
>>> checked this previously and was unable to delete folders that were
>>> created with different roles (this at least works for files created
>>> with the lcgadmin role), should I make requests at each site or is it
>>> something that we have to deal with as a VO?
>>>
>>> Erming, it looks like the problem still persists at Alberta, any news
>>> on the dcache patch?
>>>
>>> Cheers,
>>> Matt
>>>
>>> On 18 Jun 2013, at 21:57, Erming Pei wrote:
>>>
>>>> Hi Matt,
>>>>
>>>> Previously I mapped a twofold permission for normal users and
>>>> tested. It looked working for me (with multiple VO roles).
>>>> read-only all areas
>>>> read-write snoplus/users area
>>>>
>>>> However, it causes some problems as Mohammad and his student
>>>> reported. That is, for users with ONLY normal VO role will only get
>>>> read permission from snoplus/users area. They cannot read other
>>>> areas, which means only the 2nd line takes effect.
>>>> I am discussing with the dcache developers for supporting this kind
>>>> of twofold requirements but no good answers from them.
>>>>
>>>> For data deletion by normal users, this is the point I had already
>>>> raised to the dcache developers. They answered me that it's a BUG.
>>>> So they are developing a patch and it will be out soon with next
>>>> minor release.
>>>>
>>>> So now all the users have flat permissions as you previously
>>>> required. Please control it at your end as you said.
>>>> Users should be careful on data deletion operation before the patch
>>>> is applied.
>>>>
>>>> Thanks,
>>>>
>>>> Erming
>>>>
>>>>
>>>>
>>>>
>>>> On 13-06-18 11:20 AM, Matthew Mottram wrote:
>>>>> Hi Erming,
>>>>>
>>>>> I just ran some tests on file permissions on WestGrid storage. It
>>>>> looks like data that is uploaded with a production role is still
>>>>> read/writable by all users. Could this be changed, so that the
>>>>> default mode is for data to be readable by all, but writeable only
>>>>> by users with matching credentials (i.e. lcgadmin roles only can
>>>>> delete lcgadmin uploaded data)? Right now users are still able to
>>>>> read/write/delete data from any area on WestGrid storage.
>>>>>
>>>>> Cheers,
>>>>> Matt
>>>>>
>>>>> On 30 May 2013, at 16:16, Erming Pei wrote:
>>>>>
>>>>>> Hi Matt,
>>>>>>
>>>>>> You may have found the needed features are already there. I
>>>>>> re-post it here:
>>>>>> - general users can read all the data (i.e., non-production users)
>>>>>> - but can only write to
>>>>>> srm://sehn02.atlas.ualberta.ca/pnfs/atlas.ualberta.ca/data/snoplus/users/
>>>>>> area.
>>>>>> - The rest kinds of users (lcgadmin, etc) with read-only
>>>>>> permission.
>>>>>>
>>>>>> See if it's sufficient for you guys.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Erming
>>>>>>
>>>>>>
>>>>>> On 5/30/13 2:36 AM, Matthew Mottram wrote:
>>>>>>> Hi Erming,
>>>>>>>
>>>>>>> Yes, what you describe would work well for our needs.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Matt
>>>>>>>
>>>>>>> On 29 May 2013, at 17:28, Erming Pei wrote:
>>>>>>>
>>>>>>>> Hi Matt,
>>>>>>>>
>>>>>>>> Now I get what you want. Before it appeared that I got an
>>>>>>>> opposite requirement, at least for CouchDB.
>>>>>>>>
>>>>>>>> On 5/29/13 3:20 AM, Christopher J. Walker wrote:
>>>>>>>>> Can you ask this on the gridpp storage list. What you request
>>>>>>>>> seems sensible and storm can give you those permissions. Other
>>>>>>>>> SRM implementations I'm not so sire. Chris
>>>>>>>>>
>>>>>>>>> Matthew Mottram <[log in to unmask]> wrote:
>>>>>>>>>
>>>>>>>>> Hi Erming (cc Chris to see if he has any thoughts on storage
>>>>>>>>> permissions):
>>>>>>>>>
>>>>>>>>> Ah, OK. I think that we may well need to allow VO members with
>>>>>>>>> no special roles to have write permissions in the future. In
>>>>>>>>> general, we're organising our roles as follows (and following
>>>>>>>>> the scheme of other VOs):
>>>>>>>>>
>>>>>>>>> * lcgadmin: only used for software management
>>>>>>>>> * production: used for all official MC and data-processing jobs
>>>>>>>>>
>>>>>>>>> At other grid storage sites that we use, any data generated by
>>>>>>>>> the production role is automatically read-only for general
>>>>>>>>> users (or any other roles, including lcgadmin).
>>>>>>>> This should be unchanged.
>>>>>>>>> In this way, we are able to manage what users can write/delete
>>>>>>>>> as a VO rather than relying on the storage sites themselves.
>>>>>>>>> Would it be possible to revert to this?
>>>>>>>> I realise that it will mean that VO members with no special
>>>>>>>> roles will be able to write data to certain directories and
>>>>>>>> possibly even delete each other's data, however, I think this is
>>>>>>>> better than requiring a production role to write anywhere, as
>>>>>>>> this is in conflict with the practice used at other sites (and
>>>>>>>> means that we have to be careful with regards to the directory
>>>>>>>> structure used on the LFC).
>>>>>>>>>
>>>>>>>>> If it helps, I'm advising users to *only* write to a directory
>>>>>>>>> called users (so, e.g.,
>>>>>>>>> srm://sehn02.atlas.ualberta.ca/pnfs/atlas.ualberta.ca/data/snoplus/users,
>>>>>>>>> with each subdirectory the domain of specific users). We could
>>>>>>>>> just make that one directory read/write by VO members with no
>>>>>>>>> special proxy roles?
>>>>>>>>
>>>>>>>> We may control those at the storage site end. Please confirm
>>>>>>>> below is you wanted:
>>>>>>>> - general users can read all the data
>>>>>>>> - but can only write to data/snoplus/users area.
>>>>>>>>
>>>>>>>>
>>>>>>>> Erming
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Matt
>>>>>>>>>
>>>>>>>>> On 28 May 2013, at 21:27, Erming Pei wrote:
>>>>>>>>>
>>>>>>>>>> Hi Matt,
>>>>>>>>>>
>>>>>>>>>> You may need specify a VO role for "write" operation, as I
>>>>>>>>>> just changed the permission and let generic VO role with
>>>>>>>>>> read-only permission.
>>>>>>>>>> Either "production" or "lcgadmin" roles will do at this
>>>>>>>>>> moment.
>>>>>>>>>>
>>>>>>>>>> For example:
>>>>>>>>>>
>>>>>>>>>> $ voms-proxy-init -voms
>>>>>>>>>> snoplus.snolab.ca:/snoplus.snolab.ca/Role=production
>>>>>>>>>> Enter GRID pass phrase:
>>>>>>>>>> Your identity: /C=CA/O=Grid/OU=ualberta.ca/CN=Erming Pei
>>>>>>>>>> Creating temporary proxy
>>>>>>>>>> ............................................ Done
>>>>>>>>>> Contacting voms.gridpp.ac.uk:15503
>>>>>>>>>> [/C=UK/O=eScience/OU=Manchester/L=HEP/CN=voms.gridpp.ac.uk]
>>>>>>>>>> "snoplus.snolab.ca <http://snoplus.snolab.ca/>" Done
>>>>>>>>>> Creating proxy
>>>>>>>>>> .................................................................................
>>>>>>>>>> Done
>>>>>>>>>> Your proxy is valid until Wed May 29 02:21:06 2013
>>>>>>>>>>
>>>>>>>>>> $ lcg-cp -v --vo snoplus.snolab.ca
>>>>>>>>>> <http://snoplus.snolab.ca/> test2.sh
>>>>>>>>>> srm://sehn02.atlas.ualberta.ca/pnfs/atlas.ualberta.ca/data/snoplus/user/mjmottram/snotcellar/testing/temp.txt
>>>>>>>>>> Using grid catalog type: UNKNOWN
>>>>>>>>>> Using grid catalog : lfc.gridpp.rl.ac.uk
>>>>>>>>>> VO name: snoplus.snolab.ca <http://snoplus.snolab.ca/>
>>>>>>>>>> Checksum type: None
>>>>>>>>>> Destination SE type: SRMv2
>>>>>>>>>> Destination SRM Request Token: -2116324018
>>>>>>>>>> Source URL: file:/home/erming/test2.sh
>>>>>>>>>> File size: 13
>>>>>>>>>> Source URL for copy: file:/home/erming/test2.sh
>>>>>>>>>> Destination URL:
>>>>>>>>>> gsiftp://sepn03.atlas.ualberta.ca:2811/user/mjmottram/snotcellar/testing/temp.txt
>>>>>>>>>> # streams: 1
>>>>>>>>>> 13 bytes 0.03 KB/sec avg 0.03 KB/sec inst
>>>>>>>>>> Transfer took 1020 ms
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Erming
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 5/28/13 3:30 AM, Matthew Mottram wrote:
>>>>>>>>>>> Hi Erming,
>>>>>>>>>>>
>>>>>>>>>>> See output below of lcg-cp -v. The error is different now - claiming a zero number of replicas of the file locally, however, the file definitely exists and, as you can see, an lcg-cp command on the same file to a different SE is successful.
>>>>>>>>>>>
>>>>>>>>>>> [snotflow@snoplusdata ~]$ ls /home/snotflow/temp.txt
>>>>>>>>>>> /home/snotflow/temp.txt
>>>>>>>>>>>
>>>>>>>>>>> [snotflow@snoplusdata ~]$ lcg-cp -v --vosnoplus.snolab.ca <http://snoplus.snolab.ca/> temp.txtsrm://sehn02.atlas.ualberta.ca/pnfs/atlas.ualberta.ca/data/snoplus/user/mjmottram/snotcellar/testing/temp.txt
>>>>>>>>>>> Using grid catalog type: UNKNOWN
>>>>>>>>>>> Using grid catalog : lfc.gridpp.rl.ac.uk
>>>>>>>>>>> VO name:snoplus.snolab.ca <http://snoplus.snolab.ca/>
>>>>>>>>>>> Checksum type: None
>>>>>>>>>>> Destination SE type: SRMv2
>>>>>>>>>>> Destination SRM Request Token: -2116324314
>>>>>>>>>>> Source URL:file:/home/snotflow/temp.txt
>>>>>>>>>>> File size: 47893
>>>>>>>>>>> Source URL for copy:file:/home/snotflow/temp.txt
>>>>>>>>>>> Destination URL:gsiftp://sepn01.atlas.ualberta.ca:2811/user/mjmottram/snotcellar/testing/temp.txt
>>>>>>>>>>> # streams: 1
>>>>>>>>>>> 0 bytes 0.00 KB/sec avg 0.00 KB/sec inst
>>>>>>>>>>> 0 bytes 0.00 KB/sec avg 0.00 KB/sec inst
>>>>>>>>>>> 0 bytes 0.00 KB/sec avg 0.00 KB/sec inst
>>>>>>>>>>> 0 bytes 0.00 KB/sec avg 0.00 KB/sec inst
>>>>>>>>>>> 0 bytes 0.00 KB/sec avg 0.00 KB/sec inst
>>>>>>>>>>> 0 bytes 0.00 KB/sec avg 0.00 KB/sec inst
>>>>>>>>>>> 0 bytes 0.00 KB/sec avg 0.00 KB/sec inst
>>>>>>>>>>> 0 bytes 0.00 KB/sec avg 0.00 KB/sec inst
>>>>>>>>>>> 0 bytes 0.00 KB/sec avg 0.00 KB/sec inst
>>>>>>>>>>> 0 bytes 0.00 KB/sec avg 0.00 KB/sec inst
>>>>>>>>>>> 0 bytes 0.00 KB/sec avg 0.00 KB/sec inst
>>>>>>>>>>> 0 bytes 0.00 KB/sec avg 0.00 KB/sec inst
>>>>>>>>>>> 0 bytes 0.00 KB/sec avg 0.00 KB/sec inst
>>>>>>>>>>> 0 bytes 0.00 KB/sec avg 0.00 KB/sec inst
>>>>>>>>>>> 0 bytes 0.00 KB/sec avg 0.00 KB/sec inst
>>>>>>>>>>> file:/home/snotflow/temp.txt: zero number of replicas
>>>>>>>>>>> lcg_cp: Invalid argument
>>>>>>>>>>>
>>>>>>>>>>> [snotflow@snoplusdata ~]$ lcg-cp -v --vosnoplus.snolab.ca <http://snoplus.snolab.ca/> temp.txtsrm://se03.esc.qmul.ac.uk/snoplus.snolab.ca/user/mjmottram/snotcellar/testing/temp.txt
>>>>>>>>>>> Using grid catalog type: UNKNOWN
>>>>>>>>>>> Using grid catalog : lfc.gridpp.rl.ac.uk
>>>>>>>>>>> VO name:snoplus.snolab.ca <http://snoplus.snolab.ca/>
>>>>>>>>>>> Checksum type: None
>>>>>>>>>>> Destination SE type: SRMv2
>>>>>>>>>>> Destination SRM Request Token: 2f174286-eaaf-4b2f-a03f-001693ea39cf
>>>>>>>>>>> Source URL:file:/home/snotflow/temp.txt
>>>>>>>>>>> File size: 47893
>>>>>>>>>>> Source URL for copy:file:/home/snotflow/temp.txt
>>>>>>>>>>> Destination URL:gsiftp://se04.esc.qmul.ac.uk:2811//mnt/lustre_0/storm_3/snoplus.snolab.ca/user/mjmottram/snotcellar/testing/temp.txt
>>>>>>>>>>> # streams: 1
>>>>>>>>>>> 0 bytes 0.00 KB/sec avg 0.00 KB/sec inst
>>>>>>>>>>> 0 bytes 0.00 KB/sec avg 0.00 KB/sec inst
>>>>>>>>>>> 0 bytes 0.00 KB/sec avg 0.00 KB/sec inst
>>>>>>>>>>> 47893 bytes 21.32 KB/sec avg 21.32 KB/sec inst
>>>>>>>>>>>
>>>>>>>>>>> Transfer took 3120 ms
>>>>>>>>>>>
>>>>>>>>>>> [snotflow@snoplusdata ~]$ lcg-lssrm://se03.esc.qmul.ac.uk/snoplus.snolab.ca/user/mjmottram/snotcellar/testing/temp.txt/snoplus.snolab.ca/user/mjmottram/snotcellar/testing/temp.txt
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Matt
>>>>>>>>>>>
>>>>>>>>>>> On 24 May 2013, at 17:02, Erming Pei wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Matt,
>>>>>>>>>>>>
>>>>>>>>>>>> Just a quick answer at first.
>>>>>>>>>>>> What if you see in verbose way (-v)?
>>>>>>>>>>>>
>>>>>>>>>>>> Can you try lcg-cp at first, i.e, without registration to LFC.
>>>>>>>>>>>>
>>>>>>>>>>>> Erming
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 5/24/13 5:42 AM, Matthew Mottram wrote:
>>>>>>>>>>>>> Hi Erming,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'd like to be able to copy data from sites other than the westgrid login nodes to the WestGrid snoplus storage, preferably with lcg-cr and lcg-cp. For a lot of these sites, we'll be using certificates that are provided by non Canadian authorities. Currently, I'm unable to upload data, for example using a UK issues certificate and the following proxy:
>>>>>>>>>>>>>
>>>>>>>>>>>>> mm613@feynman$ voms-proxy-info --all
>>>>>>>>>>>>> subject : /C=UK/O=eScience/OU=Sussex/L=ITServices/CN=matthew mottram/CN=proxy/CN=proxy/CN=proxy/CN=proxy
>>>>>>>>>>>>> issuer : /C=UK/O=eScience/OU=Sussex/L=ITServices/CN=matthew mottram/CN=proxy/CN=proxy/CN=proxy
>>>>>>>>>>>>> identity : /C=UK/O=eScience/OU=Sussex/L=ITServices/CN=matthew mottram/CN=proxy/CN=proxy/CN=proxy
>>>>>>>>>>>>> type : proxy
>>>>>>>>>>>>> strength : 1024 bits
>>>>>>>>>>>>> path : /home/m/mm/mm613/grid/proxy/user_proxy
>>>>>>>>>>>>> timeleft : 7:21:17
>>>>>>>>>>>>> key usage : Digital Signature, Key Encipherment, Key Agreement
>>>>>>>>>>>>> === VOsnoplus.snolab.ca <http://snoplus.snolab.ca/> extension information ===
>>>>>>>>>>>>> VO :snoplus.snolab.ca <http://snoplus.snolab.ca/>
>>>>>>>>>>>>> subject : /C=UK/O=eScience/OU=Sussex/L=ITServices/CN=matthew mottram
>>>>>>>>>>>>> issuer : /C=UK/O=eScience/OU=Manchester/L=HEP/CN=voms.gridpp.ac.uk
>>>>>>>>>>>>> attribute : /snoplus.snolab.ca/Role=NULL/Capability=NULL
>>>>>>>>>>>>> timeleft : 7:22:19
>>>>>>>>>>>>> uri : voms.gridpp.ac.uk:15503
>>>>>>>>>>>>>
>>>>>>>>>>>>> and running the command:
>>>>>>>>>>>>>
>>>>>>>>>>>>> lcg-cr --vosnoplus.snolab.ca <http://snoplus.snolab.ca/> -dsehn02.atlas.ualberta.ca <http://sehn02.atlas.ualberta.ca/> -P user/mjmottram/snotcellar/testing/temp.txt -l lfn:/grid/snoplus.snolab.ca/user/mjmottram/snotcellar/testing/temp.txt temp.txt
>>>>>>>>>>>>>
>>>>>>>>>>>>> the base directories are created on the westgrid storage, however, the final file is not created. When running successfully this command should return a GUID of the entry in the LFC, however, I currently get a message like:
>>>>>>>>>>>>>
>>>>>>>>>>>>> gsiftp://sepn04.atlas.ualberta.ca:2811/pnfs/atlas.ualberta.ca/data/snoplus/user/mjmottram/snotcellar/testing/temp.txt: Success
>>>>>>>>>>>>> and then a return code of 1.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Can you help with this? Or do I *have* to use WestGrid issues certificates?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Matt
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>