The fellows here working on galaxy, about ready to release it to prime time,
came to me asking about a few sudo commands that they needed. looking into it I
came across a discussion
from last November talking about why this was being done and the security
Because I'm coming at this from the systems side, I've got a keen interest in
the security aspect of things so I've dove into this with hopes of developing
what might be a more secure approach. The issues that we have run into center
around the sudo approach taken by the three scripts: external_chown_script,
drmaa_external_killer.py and drmaa_external_runner.py.
I have read the comments from Nov on galaxy-dev on using sudo but have taken a
The issue with the external_chown_script is that is does a "sudo chown" and
"sudo chgrp" allowing the galaxy id to chown any file on the system, not just
ones involved with galaxy, and because this sudo permission is system wide, the
permission is not just via the scripts, but extends to any command line with
the galaxy id. Also, because the sudo is on "chown" and not "/bin/chown" there
is a potential of PATH manipulation to substitute in a malicious or harmful
"chown". This is a bad thing(tm).
The issue with the other two scripts (drmaa_external_runner and
drmaa_external_killer) scripts is that the sudo is on the entire script which
can be edited after the sudo is setup to contain potentially malicious/harmful
code. Also a bad thing(tm).
But you know all that, and we all know that this is a tricky issue.
1. What I have done is to create a compiled C program, to replace
external_chown_script.py. This program is intended to be installed setuid root.
I have added checks to ensure that it is used as intended and then do the
appropriate changes via the chown(2) system call. As this is to be installed
setuid root, there is no longer a need for a sudo setting on chown(1).
2. The other two scripts, because of the midstream setuid to an arbitrary user
need to also be setuid root compiled programs. After toying with some python
compilers unsuccessfully, I just coded them in C.
drama_external_killer.py is done, and I'm mostly finished
drama_external_runner.py with the exception of parsing the JT_JSON file
containing the job definitions.
Because the guys working on the galaxy install haven't quite got it running, I
don't have an example of a .jt_json file from which I can see samples of the
input to map it into drmaa_set_attribute() and drama_set_vector_attribute()
calls. Most of the keys are obvious (remoteCommand, outputPath, ...) but I
don't know how to map the following
Name - should this be DRMAA_JOB_NAME?
Email - should this be DRMAA_V_EMAIL, and if so why is it a vector?
Project - no idea where to map this
aTdHvAaNnKcSe, I plan on releasing my code, when it hardens, to the galaxy
community if there is interest in the setuid approach instead of the sudo
approach to job submission/control
| Lance Bailey, Systems
| GSC, 100-570 W 7th Ave
| 604-707-5900 x5413
| Vancouver BC, V5Z 4S6 Canada
Please keep all replies on the list by using "reply all"
in your mail client. To manage your subscriptions to this
and other Galaxy lists, please use the interface at: