[Glass] Which path to follow to limit what an user can execute ?

[James Foster via Glass]

Bruno,

Another approach is suggested by GLORP’s use of blocks for a WHERE clause. It looks like a regular block but instead of passing in each row (as implied by the usage), the block is evaluated only once and a message accumulator is passed in that implements #’doesNotUnderstand:’ to capture each message and arguments. This message accumulator is then used to generate the actual query. In conjunction with a limited SymbolList (to avoid visibility of any unauthorized globals), this could come close to what you need (but again would not be completely secure).

James

> On May 20, 2015, at 9:08 AM, James Foster <James.Foster at GemTalkSystems.com> wrote:
> 
> Hi Bruno,
> 
> Using GsObjectSecurityPolicy was a nice idea but doesn’t work quite that way. The policy is attached to objects and uses the current UserProfile to determine security. The method #’setCurrent:while:’ changes the default policy that is attached to newly instantiated objects, but does not change the current user’s access to objects that are already created.
> 
> The right way to use GsObjectSecurityPolicy would be to create a single policy, one that provides read/write permission to one user/group and read-only permission to another user/group. Then you create objects when logged in as a user with read/write permission and do your read-only operations when logged in as a user with read-only permission. That is, code obtained from XPDL files should only be executed when logged in as one user, while code written by you (to handle the forms and tasks) may be executed when logged in by a more privileged user.
> 
> To execute code as another user you need to login as that user. For that you have at least two options. The safest is probably GsExternalSession. See the class for its various protocols. You could also look at GsCurrentSession>>#’reloginAsUser:withPassword:’, though this method is intended for a situation where you are not trying to keep data between “logins”. 
> 
> As long as you are not using one of the built-in UserProfiles (such as DataCurator), you can also use the following code:
> 	System commitsDisabledUntilLogout.
> This way you would not need to set up a special GsObjectSecurityPolicy and use two UserProfiles. You would, however, still need to use a separate session (such as GsExternalSession described above). This way you can make any session effectively read-only. That is, it can still edit objects (including removing all forms), but it can’t commit so it doesn’t matter.
> 
> Here is one alternative to consider: When a method is compiled you provide a SymbolList that identifies the globals visible to the code being compiled. If this list did not include OrbeonFormProcessDefinition then it would be more difficult (though not impossible!) to reach the global. If you are trying to prevent accidental errors, then this may be sufficient. If you want to protect against malicious code, then executing it in a separate read-only session is best.
> 
> I’m not sure what you would learn from parsing the input. If you want to find out what messages are sent, you could look at the compiled method’s #’literals’ array. If you had a very limited number of approved selectors, then you could verify things that way.
> 
> Does that help?
> 
> James
> 
> 
>> On May 20, 2015, at 7:52 AM, BrunoBB via Glass <glass at lists.gemtalksystems.com> wrote:
>> 
>> Hi All,
>> 
>> I have the following problem... 
>> 
>> In my system you can import XPDL files generated with Bizagi
>> (http://www.bizagi.com/en/bpm-suite/bpm-products/modeler) and it uses Orbeon
>> forms (www.orbeon.com) to simulate each Bizagi task as an Orbeon form.
>> 
>> For example if you have a gateway in a process which split the path in two
>> different direction then you have to define a condition (inside Bizagi). 
>> The condition looks like:
>> [:formProc | (formProc age > 18) and:[formProc amount < 10000]]
>> 
>> The argument (formProc) can be an instance of OrbeonFormInstance or
>> OrbeonFormProcess.
>> The result of the evaluation MUST be a boolean.
>> 
>> Until here there is NO problem, the system execute processes WITHOUT
>> problems (even subprocesses are supported).
>> 
>> But now i want control what the user can execute inside these Blocks that
>> are defined inside Bizagi.
>> 
>> For example:
>> [:formProc | OrbeonFormProcessDefinition removeAll].
>> 
>> From the Process point of view there is no problem, the result is NOT a
>> boolean --> this process will be blocked.
>> 
>> But from Security point of view is a disaster because this will remove all
>> process instances and definitions in the system.
>> 
>> At first i thought that GsObjectSecurityPolicy will do the job. I define an
>> UserProfile ("seaside") and create a policy that only has read permission.
>> Then i use GsObjectSecurityPolicy(class)>>setCurrent:while: in order to
>> ensure that the operation is a read operation. Not sure what happend with
>> other sessions (other web users that are logged with the same UserProfile)
>> 
>> But now i'm thinking to use the Parser to check that all message that are
>> sent to the argument (formProc) and forbid the import of Bizagi models that
>> fail this check.
>> 
>> Now i'm checking the Parse and how to implement this... 
>> 
>> But what do you think about this problem ? Is there any other possible
>> solution ?
>> 
>> Regards,
>> Bruno
>> 
>> 
>> 
>> --
>> View this message in context: http://forum.world.st/Which-path-to-follow-to-limit-what-an-user-can-execute-tp4827662.html
>> Sent from the GLASS mailing list archive at Nabble.com.
>> _______________________________________________
>> Glass mailing list
>> Glass at lists.gemtalksystems.com
>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>