Re: [galaxy-dev] Bug: Toolbox filters not applied in workflows
Ahh... missed that. Sorry (and thanks for putting together the page :) ). It seems like we are on the same page - I have created a Trello card for 'stronger' toolbox filters. https://trello.com/c/Sg8D2PBj It occurs to me there may another way to accomplish admin tool functionality - and in an even more locked down fashion. I think you may be able to setup another Galaxy process with a similar config but a different tool_config_file setting and it should act as its own handler+web process as well. Then you could configure your proxy so admin requests come through this process - or maybe it could have its own URL, etc Maybe this is crazy - I am sure Nate will respond is this is non-sense :). -John On Tue, Dec 17, 2013 at 6:26 PM, Eric Rasche rasche.e...@yandex.ru wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John, I've been using the dynamic jobs and they've been working beautifully! (For context, I wrote the initial revision of the Access Control page based off of my readings and experiences setting it up in galaxy). I, for one, would be in favour of stronger filters in addition to the current versions of filtering, mostly due to my/IT's paranoid nature :) The current filters seem to accomplish exactly what they were designed to, and I see no reason to replace them. On 12/17/2013 06:15 PM, John Chilton wrote: Agreed with Dannon, it is a bug that they are showing up in the workflow editor but in general toolbox filters are not meant as a security mechanism. You can block access to running specific tools (filtered or not) using dynamic job destinations. (Under dynamic job destinations documentation ( https://wiki.galaxyproject.org/Admin/Config/Jobs#Dynamic_Destination_Mapping) there is an example of enforcing dev only tools for a specific set of e-mails as well as an example of how to get a list of admin users in a dynamic job destination. These could be combined to enforce admin only tools. I think there has been some other posts on this topic... ) It is true that one can still see the options of such tools, this is something we will have to think about... Perhaps a 'stronger' filter, though I think this variant of filtering should still be an option, there are many use cases for allowing users to run tools they cannot see. -John On Tue, Dec 17, 2013 at 5:39 PM, Dannon Baker dannon.ba...@gmail.comwrote: This sounds like a bug; the primary toolbox and workflow editor toolbox should reflect the same set of tools (exception being workflow-specific control steps, etc). I've created a trello card to track this issue here: https://trello.com/c/3TxFHkYR That said, do note the warning on the dynamic toolbox filters page: [image: !] Filters will only hide Tools from the User Interface, they are still available and can be made visible by means of HTML manipulation. That said these feature is not a security feature, it is intended to separate multiple groups of Tools and simplify the ToolBoxhttps://wiki.galaxyproject.org/ToolBox . On Tue, Dec 17, 2013 at 6:27 PM, Eric Rasche rasche.e...@yandex.ruwrote: I'm running the stable copy of galaxy and noticed that some custom, administrative tools (and otherwise tools which should be restricted in access due to licensing/etc.) were showing up in normal user's toolboxes inside the workflow editor. I feel that this is a bug, as the tool filters should be applied globally and not just in terms of what tools users are restricted from seeing in the normal toolbox. For me, this presents a problem as I strongly believe any administrative tools that exist should leak as little information as possible--not their entire set of options and associated documentation. Additionally, that sort of information leakage isn't acceptable by my organisation's policies. Do I have my instance misconfigured or is this an actual bug? I have my galaxy configured according to https://wiki.galaxyproject.org/Admin/Config/Access%20Control $ hg head changeset: 11242:9d4cbf2a1c13 branch: stable tag: tip user:Nate Coraor n...@bx.psu.edu n...@bx.psu.edu date:Fri Dec 06 16:28:31 2013 -0500 summary: Add missing destination long arg to cli runner's Torque plugin and fix an incorrectly used PBS option in the sample job conf. changeset: 11216:c458a0fe1ba8 parent: 11213:6d633418ecfa parent: 11215:f79149dd3d35 user:Nate Coraor n...@bx.psu.edu n...@bx.psu.edu date:Mon Nov 04 14:56:57 2013 -0500 summary: Merge security fix for filtering tools from stable/next-stable. $ hg summary parent: 11242:9d4cbf2a1c13 tip Add missing destination long arg to cli runner's Torque plugin and fix an incorrectly used PBS option in the sample job conf. branch: stable commit: 4 modified, 34 unknown update: (current) Thank you, Eric Rasche Programmer II Center for Phage Technology Texas AM University
[galaxy-dev] Bug: Toolbox filters not applied in workflows
I'm running the stable copy of galaxy and noticed that some custom, administrative tools (and otherwise tools which should be restricted in access due to licensing/etc.) were showing up in normal user's toolboxes inside the workflow editor. I feel that this is a bug, as the tool filters should be applied globally and not just in terms of what tools users are restricted from seeing in the normal toolbox. For me, this presents a problem as I strongly believe any administrative tools that exist should leak as little information as possible--not their entire set of options and associated documentation. Additionally, that sort of information leakage isn't acceptable by my organisation's policies. Do I have my instance misconfigured or is this an actual bug? I have my galaxy configured according to https://wiki.galaxyproject.org/Admin/Config/Access%20Control $ hg head changeset: 11242:9d4cbf2a1c13 branch: stable tag: tip user:Nate Coraor n...@bx.psu.edu date:Fri Dec 06 16:28:31 2013 -0500 summary: Add missing destination long arg to cli runner's Torque plugin and fix an incorrectly used PBS option in the sample job conf. changeset: 11216:c458a0fe1ba8 parent: 11213:6d633418ecfa parent: 11215:f79149dd3d35 user:Nate Coraor n...@bx.psu.edu date:Mon Nov 04 14:56:57 2013 -0500 summary: Merge security fix for filtering tools from stable/next-stable. $ hg summary parent: 11242:9d4cbf2a1c13 tip Add missing destination long arg to cli runner's Torque plugin and fix an incorrectly used PBS option in the sample job conf. branch: stable commit: 4 modified, 34 unknown update: (current) Thank you, Eric Rasche Programmer II Center for Phage Technology Texas AM University ___ 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: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] Bug: Toolbox filters not applied in workflows
This sounds like a bug; the primary toolbox and workflow editor toolbox should reflect the same set of tools (exception being workflow-specific control steps, etc). I've created a trello card to track this issue here: https://trello.com/c/3TxFHkYR That said, do note the warning on the dynamic toolbox filters page: [image: !] Filters will only hide Tools from the User Interface, they are still available and can be made visible by means of HTML manipulation. That said these feature is not a security feature, it is intended to separate multiple groups of Tools and simplify the ToolBoxhttps://wiki.galaxyproject.org/ToolBox . On Tue, Dec 17, 2013 at 6:27 PM, Eric Rasche rasche.e...@yandex.ru wrote: I'm running the stable copy of galaxy and noticed that some custom, administrative tools (and otherwise tools which should be restricted in access due to licensing/etc.) were showing up in normal user's toolboxes inside the workflow editor. I feel that this is a bug, as the tool filters should be applied globally and not just in terms of what tools users are restricted from seeing in the normal toolbox. For me, this presents a problem as I strongly believe any administrative tools that exist should leak as little information as possible--not their entire set of options and associated documentation. Additionally, that sort of information leakage isn't acceptable by my organisation's policies. Do I have my instance misconfigured or is this an actual bug? I have my galaxy configured according to https://wiki.galaxyproject.org/Admin/Config/Access%20Control $ hg head changeset: 11242:9d4cbf2a1c13 branch: stable tag: tip user:Nate Coraor n...@bx.psu.edu n...@bx.psu.edu date:Fri Dec 06 16:28:31 2013 -0500 summary: Add missing destination long arg to cli runner's Torque plugin and fix an incorrectly used PBS option in the sample job conf. changeset: 11216:c458a0fe1ba8 parent: 11213:6d633418ecfa parent: 11215:f79149dd3d35 user:Nate Coraor n...@bx.psu.edu n...@bx.psu.edu date:Mon Nov 04 14:56:57 2013 -0500 summary: Merge security fix for filtering tools from stable/next-stable. $ hg summary parent: 11242:9d4cbf2a1c13 tip Add missing destination long arg to cli runner's Torque plugin and fix an incorrectly used PBS option in the sample job conf. branch: stable commit: 4 modified, 34 unknown update: (current) Thank you, Eric Rasche Programmer II Center for Phage Technology Texas AM University ___ 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: http://lists.bx.psu.edu/ 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: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] Bug: Toolbox filters not applied in workflows
Okay, thanks for confirming and creating the card. Yes...it's unfortunate that tool filters will not block tools entirely, but this will get it out of the users' view in one more place. On 12/17/2013 05:39 PM, Dannon Baker wrote: This sounds like a bug; the primary toolbox and workflow editor toolbox should reflect the same set of tools (exception being workflow-specific control steps, etc). I've created a trello card to track this issue here: https://trello.com/c/3TxFHkYR That said, do note the warning on the dynamic toolbox filters page: [image: !] Filters will only hide Tools from the User Interface, they are still available and can be made visible by means of HTML manipulation. That said these feature is not a security feature, it is intended to separate multiple groups of Tools and simplify the ToolBoxhttps://wiki.galaxyproject.org/ToolBox . On Tue, Dec 17, 2013 at 6:27 PM, Eric Rasche rasche.e...@yandex.ru wrote: I'm running the stable copy of galaxy and noticed that some custom, administrative tools (and otherwise tools which should be restricted in access due to licensing/etc.) were showing up in normal user's toolboxes inside the workflow editor. I feel that this is a bug, as the tool filters should be applied globally and not just in terms of what tools users are restricted from seeing in the normal toolbox. For me, this presents a problem as I strongly believe any administrative tools that exist should leak as little information as possible--not their entire set of options and associated documentation. Additionally, that sort of information leakage isn't acceptable by my organisation's policies. Do I have my instance misconfigured or is this an actual bug? I have my galaxy configured according to https://wiki.galaxyproject.org/Admin/Config/Access%20Control $ hg head changeset: 11242:9d4cbf2a1c13 branch: stable tag: tip user:Nate Coraor n...@bx.psu.edu n...@bx.psu.edu date:Fri Dec 06 16:28:31 2013 -0500 summary: Add missing destination long arg to cli runner's Torque plugin and fix an incorrectly used PBS option in the sample job conf. changeset: 11216:c458a0fe1ba8 parent: 11213:6d633418ecfa parent: 11215:f79149dd3d35 user:Nate Coraor n...@bx.psu.edu n...@bx.psu.edu date:Mon Nov 04 14:56:57 2013 -0500 summary: Merge security fix for filtering tools from stable/next-stable. $ hg summary parent: 11242:9d4cbf2a1c13 tip Add missing destination long arg to cli runner's Torque plugin and fix an incorrectly used PBS option in the sample job conf. branch: stable commit: 4 modified, 34 unknown update: (current) Thank you, Eric Rasche Programmer II Center for Phage Technology Texas AM University ___ 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: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/ -- Eric Rasche Programmer II Center for Phage Technology Texas AM University College Station, TX 77843 404-692-2048 tel:4046922048 e...@tamu.edu mailto:e...@tamu.edu ___ 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: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] Bug: Toolbox filters not applied in workflows
Agreed with Dannon, it is a bug that they are showing up in the workflow editor but in general toolbox filters are not meant as a security mechanism. You can block access to running specific tools (filtered or not) using dynamic job destinations. (Under dynamic job destinations documentation ( https://wiki.galaxyproject.org/Admin/Config/Jobs#Dynamic_Destination_Mapping) there is an example of enforcing dev only tools for a specific set of e-mails as well as an example of how to get a list of admin users in a dynamic job destination. These could be combined to enforce admin only tools. I think there has been some other posts on this topic... ) It is true that one can still see the options of such tools, this is something we will have to think about... Perhaps a 'stronger' filter, though I think this variant of filtering should still be an option, there are many use cases for allowing users to run tools they cannot see. -John On Tue, Dec 17, 2013 at 5:39 PM, Dannon Baker dannon.ba...@gmail.comwrote: This sounds like a bug; the primary toolbox and workflow editor toolbox should reflect the same set of tools (exception being workflow-specific control steps, etc). I've created a trello card to track this issue here: https://trello.com/c/3TxFHkYR That said, do note the warning on the dynamic toolbox filters page: [image: !] Filters will only hide Tools from the User Interface, they are still available and can be made visible by means of HTML manipulation. That said these feature is not a security feature, it is intended to separate multiple groups of Tools and simplify the ToolBoxhttps://wiki.galaxyproject.org/ToolBox . On Tue, Dec 17, 2013 at 6:27 PM, Eric Rasche rasche.e...@yandex.ruwrote: I'm running the stable copy of galaxy and noticed that some custom, administrative tools (and otherwise tools which should be restricted in access due to licensing/etc.) were showing up in normal user's toolboxes inside the workflow editor. I feel that this is a bug, as the tool filters should be applied globally and not just in terms of what tools users are restricted from seeing in the normal toolbox. For me, this presents a problem as I strongly believe any administrative tools that exist should leak as little information as possible--not their entire set of options and associated documentation. Additionally, that sort of information leakage isn't acceptable by my organisation's policies. Do I have my instance misconfigured or is this an actual bug? I have my galaxy configured according to https://wiki.galaxyproject.org/Admin/Config/Access%20Control $ hg head changeset: 11242:9d4cbf2a1c13 branch: stable tag: tip user:Nate Coraor n...@bx.psu.edu n...@bx.psu.edu date:Fri Dec 06 16:28:31 2013 -0500 summary: Add missing destination long arg to cli runner's Torque plugin and fix an incorrectly used PBS option in the sample job conf. changeset: 11216:c458a0fe1ba8 parent: 11213:6d633418ecfa parent: 11215:f79149dd3d35 user:Nate Coraor n...@bx.psu.edu n...@bx.psu.edu date:Mon Nov 04 14:56:57 2013 -0500 summary: Merge security fix for filtering tools from stable/next-stable. $ hg summary parent: 11242:9d4cbf2a1c13 tip Add missing destination long arg to cli runner's Torque plugin and fix an incorrectly used PBS option in the sample job conf. branch: stable commit: 4 modified, 34 unknown update: (current) Thank you, Eric Rasche Programmer II Center for Phage Technology Texas AM University ___ 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: http://lists.bx.psu.edu/ 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: http://lists.bx.psu.edu/ 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: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] Bug: Toolbox filters not applied in workflows
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John, I've been using the dynamic jobs and they've been working beautifully! (For context, I wrote the initial revision of the Access Control page based off of my readings and experiences setting it up in galaxy). I, for one, would be in favour of stronger filters in addition to the current versions of filtering, mostly due to my/IT's paranoid nature :) The current filters seem to accomplish exactly what they were designed to, and I see no reason to replace them. On 12/17/2013 06:15 PM, John Chilton wrote: Agreed with Dannon, it is a bug that they are showing up in the workflow editor but in general toolbox filters are not meant as a security mechanism. You can block access to running specific tools (filtered or not) using dynamic job destinations. (Under dynamic job destinations documentation ( https://wiki.galaxyproject.org/Admin/Config/Jobs#Dynamic_Destination_Mapping) there is an example of enforcing dev only tools for a specific set of e-mails as well as an example of how to get a list of admin users in a dynamic job destination. These could be combined to enforce admin only tools. I think there has been some other posts on this topic... ) It is true that one can still see the options of such tools, this is something we will have to think about... Perhaps a 'stronger' filter, though I think this variant of filtering should still be an option, there are many use cases for allowing users to run tools they cannot see. -John On Tue, Dec 17, 2013 at 5:39 PM, Dannon Baker dannon.ba...@gmail.comwrote: This sounds like a bug; the primary toolbox and workflow editor toolbox should reflect the same set of tools (exception being workflow-specific control steps, etc). I've created a trello card to track this issue here: https://trello.com/c/3TxFHkYR That said, do note the warning on the dynamic toolbox filters page: [image: !] Filters will only hide Tools from the User Interface, they are still available and can be made visible by means of HTML manipulation. That said these feature is not a security feature, it is intended to separate multiple groups of Tools and simplify the ToolBoxhttps://wiki.galaxyproject.org/ToolBox . On Tue, Dec 17, 2013 at 6:27 PM, Eric Rasche rasche.e...@yandex.ruwrote: I'm running the stable copy of galaxy and noticed that some custom, administrative tools (and otherwise tools which should be restricted in access due to licensing/etc.) were showing up in normal user's toolboxes inside the workflow editor. I feel that this is a bug, as the tool filters should be applied globally and not just in terms of what tools users are restricted from seeing in the normal toolbox. For me, this presents a problem as I strongly believe any administrative tools that exist should leak as little information as possible--not their entire set of options and associated documentation. Additionally, that sort of information leakage isn't acceptable by my organisation's policies. Do I have my instance misconfigured or is this an actual bug? I have my galaxy configured according to https://wiki.galaxyproject.org/Admin/Config/Access%20Control $ hg head changeset: 11242:9d4cbf2a1c13 branch: stable tag: tip user:Nate Coraor n...@bx.psu.edu n...@bx.psu.edu date:Fri Dec 06 16:28:31 2013 -0500 summary: Add missing destination long arg to cli runner's Torque plugin and fix an incorrectly used PBS option in the sample job conf. changeset: 11216:c458a0fe1ba8 parent: 11213:6d633418ecfa parent: 11215:f79149dd3d35 user:Nate Coraor n...@bx.psu.edu n...@bx.psu.edu date:Mon Nov 04 14:56:57 2013 -0500 summary: Merge security fix for filtering tools from stable/next-stable. $ hg summary parent: 11242:9d4cbf2a1c13 tip Add missing destination long arg to cli runner's Torque plugin and fix an incorrectly used PBS option in the sample job conf. branch: stable commit: 4 modified, 34 unknown update: (current) Thank you, Eric Rasche Programmer II Center for Phage Technology Texas AM University ___ 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: http://lists.bx.psu.edu/ 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: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/ - -- Eric Rasche Programmer II Center for Phage Technology Texas AM University College Station, TX 77843
