Security Model for multi-VO Transformation System

[marianne013]

Hi,

we are about to roll out the transformation system on our production server. For testing we have assigned the ProductionManagement property to the relevant user groups. But I can't see how that stops different VOs from stepping on each other's toes, i.e. how to prevent one production user with the ProductionManagement property to cancel all transformations for a different VO ? (Not that our users ever would, they are rather well behaved, but accidents do happen.)
Tagging @sfayer cause he worries about these things more than I do.
Probably a question for @andresailer
(Edited for typo.)
Daniela

[andresailer]

But I can't see how that stops different VOs from stepping on each other's toes.

As far as I know, it doesn't, and I don't think there is a way at the moment.
What kind of prevents "canceling" is the delay set in the TransformationCleaningAgent, so accidentally "cleaning" the wrong transformation doesn't cause immediate data loss.

Also giving different VOs different TransformationTypes makes it possible that each VO sees only their own and less accidental modifications.

Edit: fix quote syntax

[marianne013]

Hi Andre,

Not that we are volunteering here, but would a security model like this work:

• Production Manager can see/do anything (for backwards compatibility and so that dirac_admin can cancel rogue transformations)
• Production Operator can see/do anything to transformations in the same
  group as them: This would be inherently VO specific; we typically have something like t2k.org_user and t2k.org_production for our VOs.
• Additionally we might want to have a "Production User" role assigned to the plain user groups, so they can try out stuff. This role would then only have access to their own transformations, but nothing else. On the other hand VOs might prefer to only allow specially blessed production users to run transformations.

What do you think ?

Daniela

[andresailer]

Sounds very sensible, but I have no feeling for how complicated it would be to implement.
(Maybe ProductionSharing instead of ProductionOperator, similar to "JobSharing" for the group)

[marianne013]

We'll have a go.

[sfayer]

We've been looking at this and we have a small snag on the web interface: It only shows the buttons/menu to control the Transformations if you have the ProductionManagement role. The javascript doesn't appear to support displaying them if you have any one of a list of properties. Our suggested fix is to just always show the buttons (because if you click them on something you don't have permission for, you'll get an access denied error anyway). Any thoughts/comments on this?

(The other option would be to modify the javascript to support a list of properties, but that sounds quite involved vs just changing "Protected" to "Visible" for the menus/buttons).

The bits of relevant javascript are here, as far as I can tell "property" can't be a list:
https://github.com/DIRACGrid/WebAppDIRAC/blob/54ffd343716903b8db91da00e0c17b4fff736ce0/src/WebAppDIRAC/WebApp/static/DIRAC/TransformationMonitor/classes/TransformationMonitor.js#L308
https://github.com/DIRACGrid/WebAppDIRAC/blob/54ffd343716903b8db91da00e0c17b4fff736ce0/src/WebAppDIRAC/WebApp/static/core/js/utils/DiracApplicationContextMenu.js#L159

[marianne013]

See:
#7113
and
DIRACGrid/WebAppDIRAC#740