nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

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!

Find more posts tagged with

Comments

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/AuthenticationUtil.html#runAs(org.alfresco.repo.security.authentication.AuthenticationUtil.RunAsWork,%20java.lang.String)) 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

?

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.

Cheers,
Peter

msvoren

Can I e.g. create a custom role, which would enable invited users to WRITE to space, but not to READ?

Can this be done?

mabayona

I do no think it is possible to have write permission without read one (i.e. before writing the system has to verify that the space exists, that no other document with equal name exists, … -> Read permission.

That is again a reason why the runas functionality is needed for simple workflow: to implement this common pattern that you are looking for.

msvoren

I can't believe something like this is not already implemented..
Shouldn't executing rules be "run as admin" as default ?

mabayona

Nope, "run as admin" as default would be a HUGE security hole. It would defeat the permissions concept. However, what is needed is a controlled way to do it. ThatÂ´s why the "runas" would be a good solution.

Alfresco?

msvoren

Thank you mabayona,

Any other way to implement this?
I'm intrested in hacks, what ever.. ?

mabayona

There is a way. If you use 2.9, use an advanced workflow. With advanced workflow you got the <runas> option. The process would be something like:

=> Create an advance workflow that gets associated automatically to a entry ( using a rule):

http://wiki.alfresco.com/wiki/WorkflowAdministration#Step_7:_Integration_with_Rules_.28Optional.29

This workflow has an action can move the e.g. document entered in a space e.g."inbox" into another space not writable by the issuer since it can be run with the privileges defined in <runas>xxx</runas>.

Alternatively, you can do something similar (although more complex) in Java.

msvoren

Thank you very much, will try that!

sacco

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).

But this already is an enormous security hole. I simply set up a rule on my space to run
my script on all incoming items. As soon as anybody puts anything in my space the game is over:
my script is running as them!

Given that the Alfresco permissions model makes it impossible to run even a simple workflow
without giving, say, reviewers access to write the properties of the directory, it's absolutely
trivial to make sure that people will drop things in your trap. (I won't spell it out any further).

Frankly, I would avoid using Alfresco for anything where even simple security is relevant,
at least until they've rethought the security model entirely, especially given that almost
all of the parent permission checks are commented out in the normal distribution!

We really need basic functionality which works robustly and predictably rather than new features.

mabayona

I do not quite understand what you mean. My experience using Alfresco and its security model is VERY GOOD and i find it robust and usable. Could you give an example of your claims?

Do not forget that the security model has a very fine granularity and it is PER SPACE and per item. The fact that someone has acces to a space does no implies that has acces to other spaces.

I would appreciate an elaborated sample of what you perceive as shortcomings of actual implementation to check it against my experience using alfresco.

sacco

OK, but it'll have to be next week, as I'm already two hours late!

msvoren

I managed to work this out by creating custom role which can write but not to read.

      <permissionGroup name="JustWrite" allowFullControl="false" expose="true" >
         <includePermissionGroup permissionGroup="Write" type="sys:base" />
         <includePermissionGroup permissionGroup="AddChildren" type="sys:base"/>
      </permissionGroup>

norgan

Hi msvoren,
sorry to warm this old topic up, but asfar as I understand the security concept, you would only need addchild rights for space b. If you have "write" rights, that would allow to edit existing documents (which you must guess, ok, but still it woudl be possible).

I will have to try that out, when Im done with my current assignment. Butmay someone is faster than me ?

Norgan

marco_altieri

As I wrote on this post:
http://forums.alfresco.com/en/viewtopic.php?f=6&t=28475
I developed a new "action" that could be used to solve this kind of problems.

I would like to ask you if this solution could introduce security holes.

Thanks,
Marco

fuad_gafarov

1. Open file - <ALFRESCO_HOME>/tomcat/webapps/alfresco/WEB-INF/classes/alfresco/model/permissionDefinitions.xml

2. Add to end of code

           <!– Kept for backward compatibility - the administrator permission has   –>
          <!– been removed to aviod confusion –>
          <permissionGroup name="Administrator" allowFullControl="true" expose="false" />
         
          <!– A coordinator can do anything to the object or its childeren unless the     –>
          <!– permissions are set not to inherit or permission is denied.                 –>
          <permissionGroup name="Coordinator" allowFullControl="true" expose="true" />
         
          <!– A collaborator can do anything that an editor and a contributor can do –>
          <permissionGroup name="Collaborator" allowFullControl="false" expose="true">
             <includePermissionGroup permissionGroup="Editor" type="cm:cmobject" />
             <includePermissionGroup permissionGroup="Contributor" type="cm:cmobject" />
          </permissionGroup>
         
          <!– A contributor can create content and then they have full permission on what –>
          <!– they have created - via the permissions assigned to the owner.              –>
          <permissionGroup name="Contributor" allowFullControl="false" expose="true" >
              <!– Contributor is a consumer who can add content, and then can modify via the –>
              <!– owner permissions.                                                      –>
              <includePermissionGroup permissionGroup="Consumer" type="cm:cmobject"/>
              <includePermissionGroup permissionGroup="AddChildren" type="sys:base"/>
              <includePermissionGroup permissionGroup="ReadPermissions" type="sys:base" />
          </permissionGroup>
         
          <!– An editor can read and write to the object; they can not create    –>
          <!– new nodes. They can check out content into a space to which they have       –>
          <!– create permission.                                                          –>
          <permissionGroup name="Editor"  expose="true" allowFullControl="false" >
              <includePermissionGroup type="cm:cmobject" permissionGroup="Consumer"/>
              <includePermissionGroup type="sys:base" permissionGroup="Write"/>
              <includePermissionGroup type="cm:lockable" permissionGroup="CheckOut"/>
              <includePermissionGroup type="sys:base" permissionGroup="ReadPermissions"/>
          </permissionGroup>
         
          <!– The Consumer permission allows read to everything by default.                  –>
          <permissionGroup name="Consumer" allowFullControl="false" expose="true" >
              <includePermissionGroup permissionGroup="Read" type="sys:base" />
          </permissionGroup>


          <permissionGroup name="WriteOnly" allowFullControl="false" expose="true" >
                  <includePermissionGroup permissionGroup="Write" type="sys:base" />
        <includePermissionGroup permissionGroup="AddChildren" type="sys:base"/>
          </permissionGroup>

‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

and

       <permissionSet type="cm:content" expose="selected">

          <!– Content specific roles.                                                       –>
         
          <permissionGroup name="Coordinator" extends="true" expose="true"/>
          <permissionGroup name="Collaborator" extends="true" expose="true"/>
          <permissionGroup name="Contributor" extends="true" expose="true"/>
          <permissionGroup name="Editor" extends="true" expose="true"/>
          <permissionGroup name="Consumer" extends="true" expose="true"/>
          <permissionGroup name="RecordAdministrator" extends="true" expose="false"/>
          <permissionGroup name="WriteOnly" extends="true" expose="true"/>   
       </permissionSet>

‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Restart Alfresco.
It create new Role called WriteOnly. User not see folder but write by script.

rrbatista

Mi problema es relacionado a los permisos igual, pero en mi caso no es cuando entro por el repositorio que una carpeta llamada "Intranetpublica" me muestra un mensaje en rojo que me dice que no hay elementos para mostrar. Sinembargo si en el mismo panel izquierdo explora la carpeta debajo si que salen las carpetar hijas y a esta si que al pincharla aparecen en el lado derecho donde se pueden gestionar los permisos de estas. El problema es que en la padre no puedo gestionar los permisos..

Nota: He hecho una migracion de alfresco 3.4 a alfresco 4.0 y desde entonces no tengo los permisos, asumo que al moverlo habrá perdido los permisos, sinembargo solo esta carpeta lo ha perdido, todas las demas permanecen bien…

Alguna Idea de como podria solucionar este problema?

Gracias de antemanos