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, and

I have read the comments from Nov on galaxy-dev on using sudo but have taken a 
different approach.

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 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. is done, and I'm mostly finished 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:

Reply via email to