There are instances where using a FUSE is useful/essential for the completion of a TES task. For example, for tasks that use crypt4gh-encrypted files, using crypt4ghfs would allow the files to remain encrypted at rest and only be decrypted during read operations, greatly enhancing security.
Currently, using a FUSE in Docker requires the use of --cap-add SYS_ADMIN or --privileged flags, per this discussion. As such, I was able to use cryptgh4fs in a standalone docker container, but not in a TES implementation.
Ideally, a user would specify an image with a FUSE and specify a mount point to mount the FUSE in a TES request, and file operations in all the executors would be done with the FUSE. However, allowing individual executors to run in privileged mode could also be useful.
There are instances where using a FUSE is useful/essential for the completion of a TES task. For example, for tasks that use crypt4gh-encrypted files, using crypt4ghfs would allow the files to remain encrypted at rest and only be decrypted during read operations, greatly enhancing security.
Currently, using a FUSE in Docker requires the use of
--cap-add SYS_ADMINor--privilegedflags, per this discussion. As such, I was able to use cryptgh4fs in a standalone docker container, but not in a TES implementation.Ideally, a user would specify an image with a FUSE and specify a mount point to mount the FUSE in a TES request, and file operations in all the executors would be done with the FUSE. However, allowing individual executors to run in privileged mode could also be useful.