Sorry David for the long delay. Unfortunately I'm not aware of a setting to do this, I think each install process handles this on their own.
This is a problem, perhaps the tool shed code should go through and ensure directory permissions are set correctly - maybe all user permissions should be applied to group and other? If this is still a priority I would create an issue for this - https://github.com/galaxyproject/galaxy/issues/new.
-John
On Tue, Jul 21, 2015 at 5:05 PM, David Trudgian David.Trudgian@utsouthwestern.edu wrote:
Apologies John - hit reply instead of reply-all first time around...
Maybe this is the right place to ask about the shed_tools and tool deps directory permissions. Installing tools from the web I get a mixed bag of folder permission, some at 775, some at 777
drwxrwxr-x 43 galaxy galaxy 4.0K Apr 9 16:44 devteam drwxrwxr-x 27 galaxy galaxy 4.0K Jul 10 14:15 iuc drwxrwxr-x 4 galaxy galaxy 60 Mar 27 11:24 lparsons drwxrwxrwx 3 galaxy galaxy 28 Jun 19 09:42 ngsplot drwxrwxrwx 3 galaxy galaxy 32 Apr 9 16:40 pjbriggs
drwxrwxrwx 3 galaxy galaxy 24 Jun 23 16:41 readline drwxrwxrwx 3 galaxy galaxy 27 Jul 10 14:10 rnastar drwxrwxr-x 6 galaxy galaxy 72 Jun 23 16:40 samtools drwxrwxrwx 3 galaxy galaxy 26 Jun 23 16:36 sqlite
On a 'run as real user' setup all users need read/execute access so you can't lock down the upper-level directory holding the tools and deps. Having write open to anyone when a tool is installed is then pretty nasty as in theory someone could maliciously modify something.
Wondering if I'm missing some setting in Galaxy somewhere that would result in 775 all the time for newly installed tools and their deps?
-- David Trudgian Ph.D. Computational Scientist, BioHPC UT Southwestern Medical Center Dallas, TX 75390-9039 Tel: (214) 648-4833
Please contact biohpc-help@utsouthwestern with general BioHPC inquries.
-----Original Message----- From: galaxy-dev [mailto:galaxy-dev-bounces@lists.galaxyproject.org] On Behalf Of John Chilton Sent: Monday, July 20, 2015 7:59 AM To: lejeczek Cc: galaxy-dev@lists.galaxyproject.org Subject: Re: [galaxy-dev] galaxy folder tree permissions
It would be best practice to do this. Nate is working on packaging (.deb) and our Anisble setup to accomplish this - getting these permissions exactly correct I think will be a big part of that effort.
All of that said - if you were really going to pursue this but just install and use the tool shed normally from the Galaxy webapp it seems kind of a wasted effort. These dependencies would be installed as the Galaxy user and run arbitrary code (from a sort of sys admin perspective). So if I were going to go through this effort I would probably try to setup a separate configuration and user for installing things from the tool shed and disable the main Galaxy instance and user from doing this. That would add considerably to this effort.
Anyway - it is a best practice so I don't mean to discourage it - but realistically I don't think many Galaxy deployments have gone through this effort.
-John
On Mon, Jul 20, 2015 at 1:37 PM, lejeczek peljasz@yahoo.co.uk wrote:
hi everybody
I'd like to ask if you think it's worthwhile is pursuing finely grained tree permissions? Would this improve security to leave out everything but only files/folders necessary for writing - to galaxy user what needs to write everything else root? Or just full perms to galaxy user on whole tree is the only way?
many thanks.
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/
UT Southwestern
Medical Center
The future of medicine, today.