Hi Peter,

Thanks for the advice. I was trying to say that the potential users for
this case will run the tool on:
1. cloud instances that they own
2. PBS/Torque/SLURM interfaced HPC resources which they will have
authenticated access to.

This means that say in the worse case if some one chooses to run a
forkbomb, it will only kill her own resource. In my opinion this is no less
secure than say I wrap a forkbomb into a torque script and submit it to my
department cluster. I am accountable and traceable to any harm I do this

The benefit to users on the other hand will be that they can easily test
their arbitrary applications to run on a larger scale via the
task-parallelism provided by Swift. Once a user is satisfied with the
behavior of her task on a compute node via Galaxy, she can follow our
recipe which will concretize her implementation as a tool to be used in

Were there any scenarios you had in mind that would lead to security


On Tue, Jan 28, 2014 at 4:17 PM, Peter Cock <p.j.a.c...@googlemail.com>wrote:

> On Tue, Jan 28, 2014 at 8:26 PM, Ketan Maheshwari <ke...@mcs.anl.gov>
> wrote:
> >
> > Is it possible to write a type file "bin_or_exe" which can detect the
> > executable bit of data before they are part of Galaxy's indexed data.
> >
> > Thanks,
> > Ketan
> You haven't convinced me this is a good idea, but I would try this
> by defining a new datatype class in Python with a sniffer method
> which just checks for the executable bit (probably defined as a
> subclass of the binary datatype, see [1]) and then add this and
> its sniffer to the datatype XML file.
> Peter
> [1]
> https://bitbucket.org/galaxy/galaxy-central/src/default/lib/galaxy/datatypes/binary.py

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:

To search Galaxy mailing lists use the unified search at:

Reply via email to