permission error - used docker run

[soundharramsay]

~/software/RNAEditingIndexer$ docker run -u $(id -u ${gplab}):$(id -g ${gplab}) -v /the_path/to_your_bams:/home/gplab/software/RNAEditingIndexer/Aligned.out_sort.bam:ro -v /the_path/to_your_output_dir:/home/gplab/software/RNAEditingIndexer/result:rw your_docker_rep_name/a_name_such_as_a2i_editing_index:a_tag RNAEditingIndex -d /home/gplab/software/RNAEditingIndexer/ -l /home/gplab/software/RNAEditingIndexer/result -o /home/gplab/software/RNAEditingIndexer/result
-os /home/gplab/software/RNAEditingIndexer/result --genome mm10 Traceback (most recent call last): File "Tools/EditingIndex/A2IEditingIndex.py", line 1341, in File "Tools/EditingIndex/A2IEditingIndex.py", line 1069, in main File "Commons/general_functions.py", line 116, in init_logging_dict File "logging/init.py", line 1554, in basicConfig File "logging/init.py", line 920, in init File "logging/init.py", line 950, in _open IOError: [Errno 13] Permission denied: '/home/gplab/software/RNAEditingIndexer/result/EditingIndex.2020-04-05T09:49:07.639199.log' [6] Failed to execute script A2IEditingIndex

[mcarrara-bioinfo]

I have exactly the same problem, exactly with the same syntax and I hope this will be solved. After some search I can provide a few pointers:

• The container appears to be configured so that everything is run as in the container. Executables and permissions are set so that only root can perform the actions. However, running a container as root is highly discourage, a huge security hole, moreso if you are connecting host folders to the container: the container can do anything to the connected host folder and is quite easy to run malicious code from the container if the system is compromised.
• Running with the ID of the host user does not work because the user does not exist and, even if it existed, it has not enough privliges
• Running as the host user solves some problems but the executable still cannot be run as it is owned by root with no executable flag for "Others"
• Changing the dockerfile to attempt and change file permission does not work, due to a mix of how the container is configured (via direct GitHub clone), how docker interprets "RUN" in the dockerfile and how committing a container to an image works.

I am out of ideas. Can anyone shed some light on this error?

[guilhermetabordaribas]

~/software/RNAEditingIndexer$ docker run -u $(id -u ${gplab}):$(id -g ${gplab}) -v /the_path/to_your_bams:/home/gplab/software/RNAEditingIndexer/Aligned.out_sort.bam:ro -v /the_path/to_your_output_dir:/home/gplab/software/RNAEditingIndexer/result:rw your_docker_rep_name/a_name_such_as_a2i_editing_index:a_tag RNAEditingIndex -d /home/gplab/software/RNAEditingIndexer/ -l /home/gplab/software/RNAEditingIndexer/result -o /home/gplab/software/RNAEditingIndexer/result -os /home/gplab/software/RNAEditingIndexer/result --genome mm10 Traceback (most recent call last): File "Tools/EditingIndex/A2IEditingIndex.py", line 1341, in File "Tools/EditingIndex/A2IEditingIndex.py", line 1069, in main File "Commons/general_functions.py", line 116, in init_logging_dict File "logging/init.py", line 1554, in basicConfig File "logging/init.py", line 920, in init File "logging/init.py", line 950, in _open IOError: [Errno 13] Permission denied: '/home/gplab/software/RNAEditingIndexer/result/EditingIndex.2020-04-05T09:49:07.639199.log' [6] Failed to execute script A2IEditingIndex

Hello dear, soundharramsay

I'm using docker version 19.03.12 and ubuntu 18.04. I ran it successfully using "--user root" instead of " -u $(id -u ${gplab}):$(id -g ${gplab})". Unfortunately i don't know why, but it works. I also used /data directory instead /home.

[mcarrara-bioinfo]

Hello guilhermetabordaribas,

Thank you for the answer. Using the root user works because the privileges are transferred from guest to host directly, when writing on the host folder.

The practice of running a container as root is highly discouraged for this reason, because you can damage the host folders or open a path for an attacker based on guest escape and privilege escalation.

Based on my tests, this behavior can be easily solved by changing the software so that it does not require root privileges to run. Right now the scripts work on files and folders that have either specific group permissions or root-only access.

The solution is to change the scripts so that they read and write files and folders accessible to anyone (+rwx for other).

I tried to do this myself, in order to fork and release, but handling permission in containers is not my thing and, if I'm not mistaken, an inner script works inside a guest system folder, making the effort quite useless again for safety concerns (and for the fact that I don't have the time to review the whole code hoping to find the culprit)