DRMAA chmod to world-writable if to user chown fails should not be default?
Hi, Looking through the DRMAA job runner code I noticed that in lib/galaxy/jobs/__init__.py:1582 that if chown to a user in change_ownership_for_run fails then there is chmod 0777 instead. I'm thinking that this probably shouldn't happen by default, or there needs to be a big warning on the wiki? I understand the world-readable security concerns posted there - but world-writable, for whatever reason, on a shared cluster seems like a disaster waiting to happen. Maybe either warn on the wiki, make the chmod 777 a non-default option, or an option to disable it? DT ________________________________ UT Southwestern Medical Center The future of medicine, today.
Yeah - I am with you on this. It is definitely less than ideal that any exception will cause that to happen. Here is a commit that I believe should fix the problem: https://github.com/galaxyproject/galaxy/commit/87e19aa4d708d6c719b396867f431... Do you have a working run-as-real user setup to test this - it would take some time for me to test this but if you have something ready to go - let me know and I will open a PR :). Also - I noticed the documentation for the run-as-real-user stuff seems to match the code implementation - can you peak at https://github.com/galaxyproject/galaxy/pull/94 and let me know if it more accurately reflects how you got things up and running? Thanks for finding and reporting this issue! -John On Mon, Mar 30, 2015 at 3:33 PM, David Trudgian < David.Trudgian@utsouthwestern.edu> wrote:
Hi,
Looking through the DRMAA job runner code I noticed that in lib/galaxy/jobs/__init__.py:1582 that if chown to a user in change_ownership_for_run fails then there is chmod 0777 instead.
I’m thinking that this probably shouldn’t happen by default, or there needs to be a big warning on the wiki? I understand the world-readable security concerns posted there – but world-writable, for whatever reason, on a shared cluster seems like a disaster waiting to happen.
Maybe either warn on the wiki, make the chmod 777 a non-default option, or an option to disable it?
DT
------------------------------
UT Southwestern
Medical Center
The future of medicine, today.
___________________________________________________________ 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: https://lists.galaxyproject.org/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
John, Looks good. I’m afraid I can’t test this on our main install any more, but I do have a VM somewhere at home which will let me test in a reasonable amount of time. I could probably look at that by the end of the week. Sorry I can’t do it straight away. Cheers, DT From: John Chilton [mailto:jmchilton@gmail.com] Sent: Wednesday, April 08, 2015 8:12 AM To: David Trudgian Cc: galaxy-dev@lists.galaxyproject.org Subject: Re: [galaxy-dev] DRMAA chmod to world-writable if to user chown fails should not be default? Yeah - I am with you on this. It is definitely less than ideal that any exception will cause that to happen. Here is a commit that I believe should fix the problem: https://github.com/galaxyproject/galaxy/commit/87e19aa4d708d6c719b396867f431... Do you have a working run-as-real user setup to test this - it would take some time for me to test this but if you have something ready to go - let me know and I will open a PR :). Also - I noticed the documentation for the run-as-real-user stuff seems to match the code implementation - can you peak at https://github.com/galaxyproject/galaxy/pull/94 and let me know if it more accurately reflects how you got things up and running? Thanks for finding and reporting this issue! -John On Mon, Mar 30, 2015 at 3:33 PM, David Trudgian <David.Trudgian@utsouthwestern.edu<mailto:David.Trudgian@utsouthwestern.edu>> wrote: Hi, Looking through the DRMAA job runner code I noticed that in lib/galaxy/jobs/__init__.py:1582 that if chown to a user in change_ownership_for_run fails then there is chmod 0777 instead. I’m thinking that this probably shouldn’t happen by default, or there needs to be a big warning on the wiki? I understand the world-readable security concerns posted there – but world-writable, for whatever reason, on a shared cluster seems like a disaster waiting to happen. Maybe either warn on the wiki, make the chmod 777 a non-default option, or an option to disable it? DT ________________________________ UT Southwestern Medical Center The future of medicine, today. ___________________________________________________________ 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: https://lists.galaxyproject.org/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
participants (2)
-
David Trudgian -
John Chilton