Ownership/permissions on retrieved files

[jackleland]

Currently the minio command for retrieving from the Object Store does not allow you to set what permissions the file is created with. As such, all files and directories created are defaultly made to be owned by the nlds user, with the group being set to either the current directory's group or the default value (gws_cedaproc currently). Further to this, all files will by default be written with 644 octal permissions, meaning they can't be read/copied or moved/deleted.

To allow them to be read we will need to manually chmod (or python equivalent) each file to add group write permissions (and execute permissions if necessary) and ensure that the group set on the file matches the group of the user who originally uploaded (we can't change the owner unfortunately).

To them to be moved we need to +wx to all parent directories, which again can be done with a chmod

[jackleland]

@nmassey001

[nmassey001]

@jackleland Yes, I had to do something similar with NLDS (in that case, files were retrieved as root). I can dig the code out. I was able to change the owner - we might have to change permissions, change the owner, then change permissions again. We could also give the nlds user sudo permissions to change the owner.

We really need to return the files to either the user who uploaded them, or the user who downloaded them. I think the users might actually prefer the latter. I've had comments from the CANARI team that they expected files to be their user name when downloading files from their colleagues.

[jackleland]

I would certainly prefer to return them to being owned by the downloading user, but currently that doesn't seem possible with how the filesystem is mounted, I will do some testing...

[jackleland]

@nmassey001 We can't sudo on the kubernetes deployment, so I don't think it will be possible to change the ownership of files

[jackleland]

Found a fix for this using a deployment specific solution, i.e. fixing on the container side as opposed to in the code base. This, I think, maintains the portability of the code as having access to chown is not a given, sometimes it will be deployed with root privileges or with access to a sudoers file. This solution does however require the use of a specific, modified chown binary name (chown_nlds) which only allows files owned by the nlds to have their ownership changed. As of c512332 the binary used to change ownership of files is configurable, so this is addressed.