You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Docker containers with non-root users will fail silently with exit code 2 if MiniWDL's run directory belongs to a secondary group and has the group sticky bit set
#706
Open
adamnovak opened this issue
Jul 17, 2024
· 0 comments
I tried to run a MiniWDL workflow with --dir output/miniwdl-runs, to put its work and output in that directory. That directory has permissions and ownership:
drwxr-sr-x 7 anovak patenlab 6 Jul 17 08:25 .
It belongs to the patenlab group, and has the group sticky bit set, so files and directories I create within it will by default also belong to the patenlab group, and for directories will also have the group sticky bit set.
But my current selected group is the prismuser group:
$ id -gn
prismuser
When MiniWDL makes the stdout.txt and stderr.txt files for tasks under its run directory, they end up being owned by patenlab. But when MiniWDL decides what groups to grant to the containers it runs, it gets only the currently selected ("effective") group ID and grants just that group:
# add invoking user's group to ensure that command can access the mounted working
# directory even if the docker image assumes some arbitrary uid
groups= [str(os.getegid())]
If you run a container that runs as root in the container (the Docker default, usually), this works fine, because the container's root user gets to do anything it wants to any file mounted into the container. But if the Docker container image is built to run as a different user (like biocontainers/samtools@sha256:3ff48932a8c38322b0a33635957bc6372727014357b4224d420726da100f5470 which is built to run as the user biodocker with ID 1000), then the passed group does not actually grant the container permission to write to the task standard output and standard error files (or the task working directory).
But if you consult stdout.txt and stderr.txt, they are empty (since the container couldn't write to them).
(This is very hard to debug; probably in the situation where MiniWDL got nothing from any of the stuff it injected into the container, it ought to show the service-level logs to the user.)
If you run with --debug (or maybe with --verbose? I used both), you get access to the actual Docker service logs, which are a little more useful:
Probably what MiniWDL should do is check what group the task working directory actually got, and pass that group along to the container, instead of or in addition top the user's primary group. If the user is relying on group-level access to read workflow inputs, and the workflow inputs maybe get mounted into the container in place (not sure if this happens), then MiniWDL should really give the container all the user's groups.
A different solution might be to set the group on the run's top-level directory when it is created, so then we can rely on it matching the effective group of the MiniWDL process.
The text was updated successfully, but these errors were encountered:
I tried to run a MiniWDL workflow with
--dir output/miniwdl-runs
, to put its work and output in that directory. That directory has permissions and ownership:It belongs to the
patenlab
group, and has the group sticky bit set, so files and directories I create within it will by default also belong to thepatenlab
group, and for directories will also have the group sticky bit set.But my current selected group is the
prismuser
group:When MiniWDL makes the
stdout.txt
andstderr.txt
files for tasks under its run directory, they end up being owned bypatenlab
. But when MiniWDL decides what groups to grant to the containers it runs, it gets only the currently selected ("effective") group ID and grants just that group:miniwdl/WDL/runtime/backend/docker_swarm.py
Lines 457 to 459 in 5ccead0
If you run a container that runs as root in the container (the Docker default, usually), this works fine, because the container's root user gets to do anything it wants to any file mounted into the container. But if the Docker container image is built to run as a different user (like
biocontainers/samtools@sha256:3ff48932a8c38322b0a33635957bc6372727014357b4224d420726da100f5470
which is built to run as the userbiodocker
with ID 1000), then the passed group does not actually grant the container permission to write to the task standard output and standard error files (or the task working directory).Then you get logs like this:
But if you consult stdout.txt and stderr.txt, they are empty (since the container couldn't write to them).
(This is very hard to debug; probably in the situation where MiniWDL got nothing from any of the stuff it injected into the container, it ought to show the service-level logs to the user.)
If you run with
--debug
(or maybe with--verbose
? I used both), you get access to the actual Docker service logs, which are a little more useful:Probably what MiniWDL should do is check what group the task working directory actually got, and pass that group along to the container, instead of or in addition top the user's primary group. If the user is relying on group-level access to read workflow inputs, and the workflow inputs maybe get mounted into the container in place (not sure if this happens), then MiniWDL should really give the container all the user's groups.
A different solution might be to set the group on the run's top-level directory when it is created, so then we can rely on it matching the effective group of the MiniWDL process.
The text was updated successfully, but these errors were encountered: