Several problems with permissions management

[Cameron-Van-Eck]

Hello:

Apologies if this is the wrong repository to submit this to; it's not clear to an outsider which repository is responsible for which functionality.

I am having problems, or at least undesired behaviour, while trying to set access permission for files on arc.

Case 1: assigning a read group and a write group

• Desired behaviour: file has a group assigned with read/write permissions, and a separate group with read-only permissions.
• Actions: File initially has no permissions set. Using web-interface or vchmod (behaviour is same in both cases), set read access to POSSUM_Members group; vchmod g+r arc:/projects/CIRADA/polarimetry/ASKAP/Pilot/Pipeline_V0.3/SB34120/SB34120_pipeline.csv "POSSUM_Members". So far so good: web interface reports correct read permissions. Set write access for CIRADA-Polarimetry group: vchmod g+w arc:/projects/CIRADA/polarimetry/ASKAP/Pilot/Pipeline_V0.3/SB34120/SB34120_pipeline.csv "CIRADA-Polarimetry". Command executes without error message. Web interface shows that file now has read/write permissions for correct group, but no read-only permissions set.
• Outcome: The POSSUM_Members group no longer has read access, despite it being set in the initial command.

Case 2: Attempting to reverse previous problem and/or remove write permissions.

• Desired behaviour: read-only access group can be reassigned, even if it means remove the read/write group.
• Actions: Attempt to assign read permissions again by repeating previous command: vchmod g+r arc:/projects/CIRADA/polarimetry/ASKAP/Pilot/Pipeline_V0.3/SB34120/SB34120_pipeline.csv "POSSUM_Members". Command executes without error, but no change is seen in permissions. Attempt to remove read/write permissions from other group: vchmod g-w arc:/projects/CIRADA/polarimetry/ASKAP/Pilot/Pipeline_V0.3/SB34120/SB34120_pipeline.csv "CIRADA-Polarimetry" produces a Python error:

Traceback (most recent call last):
  File "/opt/anaconda3/bin/vchmod", line 8, in <module>
    sys.exit(vchmod())
  File "/opt/anaconda3/lib/python3.8/site-packages/vos/commands/vchmod.py", line 89, in vchmod
    raise ArgumentError(
  File "/opt/anaconda3/lib/python3.8/argparse.py", line 737, in __init__
    self.argument_name = _get_action_name(argument)
  File "/opt/anaconda3/lib/python3.8/argparse.py", line 719, in _get_action_name
    elif argument.option_strings:
AttributeError: 'list' object has no attribute 'option_strings' 

• Attempting to remove write permissions by using the web-interface: open the edit permissions interface, delete the group name from the Write Group list, press save. After reloading, the permissions appear the same -- the write group still contains CIRADA-Polarimetry.
• The only workaround I have found it to use vchmod g=r which moves the write permission group to have read permissions, and then it can be replaced by the group I want to actually have read permission.

Conclusions: the current behaviour of the permission system is that I can have either a read group, or a write group, but not both. Once a write group is set for a file, it can not be removed. This has the potential to be a significant problem for us: we have a team of people who will want/need write access to files, to be able to move them around or replace them as necessary, and we have a larger team for whom we want to grant read access but not the ability to change the data. As is, we can grant the read access but then the file can only be moved/changed by the team member who uploaded it first.

Additional complaints, although less important:

• It does not seem the files, when uploaded, inherit any permissions from their parent folder. It may be an open question as to whether this is a generally desirable behaviour (it is from my perspective). It is mildly tedious to have to edit the file permissions manually one-by-one after uploading new files.
• The 'Recursive' functionality (which I interpret to mean recursive through directories, although this is not explicit) does not seem to work. I don't have a clear demonstration of this right now, but I have tried several times in the past and each time using the web-interface it fails to actually change the file permissions.

Please let me know if I've misunderstood the nature of the permissions system and am trying to do something it was not intended to support.

Thanks, Cameron Van Eck

[brianmajor]

Hi @Cameron-Van-Eck - I haven't read through the details of your issue yet, but thought i could point to some /arc specific documentation on permssions which may be of some help.

https://github.com/opencadc/skaha/tree/master/doc#groups-and-permissions

[Cameron-Van-Eck]

Hi Brian (and anyone else involved):

I've returned to dealing with arc permissions again today. The documentation linked above was very interesting (and I had not seen it before, so thank you for sharing it), but I don't know that it addresses the heart of my problems: if it is intended that we should be able to manipulate permissions using either the browser interface or the vos command line tools, then those are not functioning in the ways I expect (and need, given my current model for how we will be sharing data with users).

I have a nitpick/complaint about that documentation. I'm interested in the command line tools described here, but it's not clear where I use them. Running them similarly to the vos tools on my machine, with a syntax to the effect of getfacl arc:<path> produces a "No such file" error, suggesting it's not intended for remote access. Creating a desktop session within the Science Portal and attempting to run it there gives a "command not found" error:

cwd: /arc/projects/CIRADA/polarimetry/ASKAP/Pilot
 > getfacl
bash: getfacl: command not found

In what environment should I be running the getfacl/setfacl commands?

Thanks, Cameron

[brianmajor]

Hi @Cameron-Van-Eck , sorry for the slow response.

You are correct in that the setfacl/getfacl commands are to be run from within the science platform in the /arc/... directory tree. It also seems that many common containers (such as the skaha terminal in a desktop session) do not have those tools installed. I will make tasks on our side to update the documentation and to install the tools in some containers. I see that most jupyter notebooks seem to have setfacl installed, such as images.canfar.net/skaha/skaha-notebook:22.03, so you can use the jupyter lab terminal for now.

[exalate-issue-sync[bot]]

Helena Jeeves commented: Need to investigate further.

[exalate-issue-sync[bot]]

Helena Jeeves commented: Thanks for the very detailed assessment Cameron! And thanks for sticking with it until you found a workaround. Sorry it came to that, though. 😞

I’ve been able to reproduce everything you’ve brought up, and will be raising it as a design/development issue so the work to fix the UI can be scheduled.

About the ‘recursive’ option - I don’t think it’s supported by arc at all. I get a 500 error when I try to use the option. (The POST data contains ‘recusrive’, which I think is why the 500 error shows. On any other attempts to change permissions, it’s not contained in the data.)

• Helena J.