Permission to execute script

[msvoren]

I have following situation:

Person has permission to read and write in Space A. He can NOT see Space B.
There's a rule which executes script and moves inbound content from Space A to Space B.
It goes like this: person uploads content to A, script moves it to B.

How can this be done?  For what I see now, script will not execute, and uploaded file stays in A..

Help please!

[pmonks]

For this kind of use case you'll have to drop to Java.  Within the Foundation Services API (http://wiki.alfresco.com/wiki/Java_API) there's a class / method called "AuthenticationUtil.runAs" (http://dev.alfresco.com/resource/docs/java/repository/org/alfresco/repo/security/authentication/Auth...) that'll do what you're after.

We don't expose this kind of functionality to Javascript because it creates serious security holes (ie. a user could upload a script that runs as admin and then deletes all content in the repo).

Cheers,
Peter

[mabayona]

An easy solution would be for Alfresco to implement/extend the <runas> functionality for actions associated to simple workflows (as now has been implemented for actions in advanced workflows). This would allow to safely implement this rather common scenario.

Alfresco?

[pmonks]

Recall that end users can upload Javascript actions which is one of the way rules (whether related to simple workflow or not) can be implemented.  Anything that end users can do script wise must be locked down from a security perspective (ie. the script must not be allowed to "run as" another user, amongst other things).

Scripts inside Advanced Workflows are different in that they can only be uploaded by developers or (via the Workflow Console) administrators - either of those types of users already have sufficient privileges that there's little we can do if they decided to do something malicious to Alfresco or the server it's running on.  End users, on the other hand, do not typically have that level of access to the system and it would be a serious bug if we allowed (whether inadvertently or not) that level of access.

Cheers,
Peter

[mabayona]

To mantain the security level, the <runas> can be restricted to the roles available to the person that created the rule/simple workflow. This way, it is possible to implement this common scenario and the implementor can only select the roles available to him/her.

This way, only an "admin" can create a <runas>admin</runas> while, say "approver" can only use his rights to define rule associated to an action and make it available to users with less privileges (e.g. to create a "inbox" space where users can put documents and to create a rule in this inbox space to allow the documents to be moved to another space where the document providers have either no access or read-only access.

The way to implement it would be by extending the UI and including an extra drop-menu with the available roles to the rule creator.

[pmonks]

Roles are specific to spaces however, so how would this help with your original scenario (user A has R/W role in space A but has no R/W roles in space B, and they need to run a script that moves a document from space A to space B)?

Cheers,
Peter

[mabayona]

It would help in the sense that it would allow the space owner to implement this scenario in its space. It would allow, for instance, to create e.g. a subspace "inbox" for role "providers" and R/W in "inbox", and to create a rule with <runas>approver</runas> permission in "inbox" to move the document to another sub-space e.g. "pending approval" where "providers" do not need to have write permission. This is the scenario which is very common, but that now is not possible to implement with simple workflow.

Of course, alternatives are to resort either to java or to advanced workflow (where <runas> is available).

[pmonks]

Again that would be a security risk, since it would allow users who have a R/W role in one space (eg. their user home) to upload a script that effectively has R/W access to any other space in the system.  In other words, roles always have to be applied in the context of a space.

That said, I understand the problem and can't help wondering if explicit identification of "developer scripts" and "end user scripts" might help.  "Developer scripts" would only be able to be created by developers and would have the ability to "runas" etc., while "end user scripts" could be created by anyone but would remain locked down within the current scripting security sandbox.

Interestingly enough, in 2.1.3 this distinction has already started appearing - Javascript scripts loaded from the classpath are trusted (ie. are "developer scripts") and have full access (via Rhino's native Java integration) to Java APIs (including the Foundation Services API), while Javascript scripts loaded from the repository are not trusted (ie. are "end user scripts") and run within the scripting security sandbox.  The only missing piece here would be to expose a "runas" Javascript API that's only available to "developer scripts" (Alfresco's existing Java "runas" API is not readily usable from Javascript due to the use of callbacks).

This would be a good enhancement request (http://issues.alfresco.com/)!

Cheers,
Peter

[mabayona]

I understand your proposal to diferentiate between "developper scripts" and "end user scripts". It is probably a starting point to solve the missing functionality "runas" for simple workflow users.

What i do not quite understand is when you say that:

"Again that would be a security risk, since it would allow users who have a R/W role in one space (eg. their user home) to upload a script that effectively has R/W access to any other space in the system. In other words, roles always have to be applied in the context of a space."

since these actions/rules would be only executable in the space where they were created (i.e. uploaded document/script) and would have the permissions defined for them ONLY for the specific spaces where the rule (e.g. move to another space in simple workflow) and with the permissions allocated to them by the rule creator (i.e. its permissions and no others). Note that I´m talking about rules associated to spaces and not "execute an action" in any space.

Anyway, something should be done to cover this missing "runas" functionality for simple workflow if we really want "normal-joe-user" to create and use simple workflows effectively in Alfresco.

[pmonks]

How about you raise an enhancement request (at http://issues.alfresco.com/), and post a link to it back here?  Things tend not to happen spontaneously.  :wink:

Cheers,
Peter