Hi Peter, On Nov 25, 2010, at 7:55 PM, Peter wrote:
On Thu, Nov 25, 2010 at 6:16 PM, Pieter Neerincx <pieter.neerincx@gmail.com> wrote:
Hi Alex and Peter,
On Nov 24, 2010, at 8:32 PM, Bossers, Alex wrote:
Indeed if you are talking plugging in real tools that require binaries or perl scripts to be installed on the server that might / that is a serious security issue. We had the same discussion internally about a tool we have that allows the load and execution of ANY uploaded R script for testing... That tool will never make it to the production server :)
It might be an option to allow this kind of actions by restricting it to dedicated galaxy admins (as specified in the galaxy universe_wsgi.ini file). I haven't figured out how to restrict tools to this GROUP of users in galaxy though....
Sure, being able to plug any tool is a security risk, but if I understood correctly, tools published in the 3rd party tool shed need to be approved by the Galaxy team 2 Penn State. So, I can imagine a system where users can only add approved and signed 3rd party tools from the tool shed.
Well, it would be quite a lot harder and more time consuming for them to approve tools if they also had the additional responsibility for checking for malicious code. There is also no code signing functionality in the tool shed (yet).
Yep and it probably also means it will take longer for a tool to get approved. On the other hand though, if the Galaxy team at Penn State doesn't do it and you worry about malicious code you'll have to do it yourself... The question is do you? Do you manually inspect the code of each and every Perl module you install, every Python egg you fetch, every jar you add, etc.? In fact did you inspect the Galaxy code to check whether it doesn't open a back door? Maybe I should, but to be honest I never do. I simply don't have the time to do that, so if it comes from a reasonably respectable source, I'll install those 3rd party tools, otherwise I don't.
There needs to be a balance between allowing users to experiment as freely as possible - after all most of us are into science :) - and preventing users from destroying the infrastructure. Restricting dynamic tool plugging to admins would be another option, but the less end users need to beg admins for customizations, upgrades, etc., the better!
I would say when it comes to servers, customizations and upgrades are things best left to administrators (if you expect any kind of stability and reliability from your Galaxy install). In many cases tool wrappers from the Tool Shed would depend on 3rd party tools which must still be installed manually. Only a minority of tools will be standalone and thus could be installed "automatically" anyway.
Check, I'm aware of the technical implications and limitations, but one can dream :). In my local Galaxy I have several tools with dependencies whose installation procedures seem to be designed in hell, so for those it won't fly. On the other hand, I also added some tools that use pure bash or Perl without any dependencies on modules that are not part of a basic install, so for those it could work :). Granted, to prevent security and dependency issues, the easiest way is to stick to web services and thanks to the work from Sumedha et al. we already can :) Cheers, Pi
Peter
------------------------------------------------------------- mobile: +31 6 143 66 783 e-mail: pieter.neerincx@gmail.com skype: pieter.online -------------------------------------------------------------