DRMAA chmod to world-writable if to user chown fails should not be default?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

DRMAA chmod to world-writable if to user chown fails should not be default?

David Trudgian

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/
Reply | Threaded
Open this post in threaded view
|

Re: DRMAA chmod to world-writable if to user chown fails should not be default?

John Chilton-4
Yeah - I am with you on this. It is definitely less than ideal that any exception will cause that to happen.


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 <[hidden email]> 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/


___________________________________________________________
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/
Reply | Threaded
Open this post in threaded view
|

Re: DRMAA chmod to world-writable if to user chown fails should not be default?

David Trudgian

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:[hidden email]]
Sent: Wednesday, April 08, 2015 8:12 AM
To: David Trudgian
Cc: [hidden email]
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/87e19aa4d708d6c719b396867f431d94c92077c5

 

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 <[hidden email]> 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/

 


___________________________________________________________
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/