Looking up a user's group membership from a rule

[Tony Edgin]

Hi everyone.

Using the acPreProcForModifyAccessControl rule, I'm trying to prevent a user from changing the ACL for any other user belonging to the rodsadmin group.  I can't seem to find a microservice that provides group membership information for a given user.  Is there such a microservice?

Thanks in advance.

Tony

[Jean-Yves Nief]

hello,

there is no such microservice. However, you can query the
database to find the information using msiMakeGenQuery:
clients/icommands/test/rules3.0/rulemsiExecGenQuery.r
the attributes you should work with in your case, should be USER_TYPE.
hope this help,
JY

> --
> "iRODS: the Integrated Rule-Oriented Data-management System; A
> community driven, open source, data grid software solution"
> https://www.irods.org
>
> iROD-Chat: http://groups.google.com/group/iROD-Chat

[Antoine de Torcy]

Hi Tony,

There might be several ways to implement this with rules and microservices. Here is one example, made very simple thanks to the new rule language's syntax. I have defined two rules: one that queries the iCAT to test if a given username is that of an admin, and a modification of acPreProcForModifyAccessControl that aborts the operation if a non-admin user tries to modify access control for an admin. To enable these rules just add custom.re to your iRODS/server/config/reConfigs/ directory and edit your iRODS/server/config/server.config to list the additional rule definition file: 'reRuleSet custom,core' in this order, comma separated (without spaces I believe). No need to rebuild or restart your iRODS server here.

You may notice that had to I use cut and fail to abort the operation, and that the error message returned by the client (at least with ichmod) looks more like debugging info than a "not enough privilege" message you would expect here. This could possibly be refined in future updates to the rule engine, as per Hao's comments.

Feel free to give this a shot a see if it works for you.
Cheers,

AdT

[Reagan Moore]

Antoine:

In the acIsRodsAdmin the last operation is the conversion of a string to a boolean value.

I did not see how the execution of acIsRodsAdmin is associated with the boolean value.

Reagan

[Antoine de Torcy]

Reagan:

By having bool(*isAdmin); as the last instruction in acIsRodsAdmin it not only does the conversion but also makes the resulting boolean acIsRodsAdmin's return value. This allows to use acIsRodsAdmin(*UserName) directly as a condition. I learnt that trick from Hao. The previous version of acIsRodsAdmin contained:
if (*isAdmin) { succeed; } else {fail; }
And would be used like this:
acPreProcForModifyAccessControl(...) { on (acIsRodsAdmin(*UserName) >= 0) { ... } }

Antoine

[Jean-Yves Nief]

hello Antoine,

Antoine de Torcy wrote:
> Hi Tony,
>
> There might be several ways to implement this with rules and microservices. Here is one example, made very simple thanks to the new rule language's syntax. I have defined two rules: one that queries the iCAT to test if a given username is that of an admin, and a modification of acPreProcForModifyAccessControl that aborts the operation if a non-admin user tries to modify access control for an admin. To enable these rules just add custom.re to your iRODS/server/config/reConfigs/ directory and edit your iRODS/server/config/server.config to list the additional rule definition file: 'reRuleSet custom,core' in this order, comma separated (without spaces I believe). No need to rebuild or restart your iRODS server here.
>
> You may notice that had to I use cut and fail to abort the operation, and that the error message returned by the client (at least with ichmod) looks more like debugging info than a "not enough privilege" message you would expect here.

there is already a msiExit msi which allows to put a message of your
choice in the error stack. However, this error stack was not printed out
for almost all the icommands. I have added this into almost all the
icommands a month ago, so it will available in the next release. Hence
admins will be able to pass to the client a customized error message of
their own.
cheers,
JY

> This could possibly be refined in future updates to the rule engine, as per Hao's comments.
>
> Feel free to give this a shot a see if it works for you.
> Cheers,
>
> AdT
>
>
>
>

[Antoine de Torcy]

Thanks Jean-Yves. In a quick test I am getting the same behavior here with msiExit instead of fail, and it's a bit cleaner.

AdT

[Tony Edgin]

Thanks guys.  

I've noticed if instead of the cut, msiExit combination, an error code is used, the error message on the client's command line looks better.  For instance.

acPreProcForModifyAccessControl(*RecursiveFlag,*AccessLevel,*UserName,*Zone,*Path) {

    on (acIsRodsAdmin(*UserName) && !acIsRodsAdmin($userNameClient)) {

#        cut; 

#        msiExit("-830000","Operation not permitted"); 

        -830000;

    } 

}

Is this an allowed form, or am I taking advantage of looseness in the rule parser?

I would only use this form until msiExit is supported by the other icommands.

Cheers,

Tony

On Thu, Jul 5, 2012 at 11:18 AM, Antoine de Torcy <adet...@email.unc.edu> wrote:

Thanks Jean-Yves. In a quick test I am getting the same behavior here with msiExit instead of fail, and it's a bit cleaner.

AdT

[Hao Xu]

Hi Tony,

In this form where the rule has a negative integer as its last action, the rule engine actually thinks the rule as being successful. The reason that it works is probably because of the particular way this event hook (and some other event hooks) is handled by the rule engine and related code. Therefore, it is not encouraged to used this approach as a general method for representing a failure. I think it is ok if it works for you in this particular event hook, but I would use the cut/msiExit combination (alternatively you can use cut/fail combination, but you still get the generic "cut error"), as it tells the rule engine that the rule actually fails. (Thanks Jean-Yves for patching the icommands!)

In future release we can enhance the cut microservice to do more, such as allowing customised error code and error messages.

  Hao

[Tony Edgin]

Thanks Hao.  I'll switch over to cut/msiExit on 3.2 is released.

Back to my original question.  Using the USER_TYPE field solves the problem I stated, but I had simplified my problem a bit.  

We use groups to distinguish two classes of users with administrator type users.  One group just has ownership of everything.  This group of privileged users is not allowed to remove another privileged user's ownership of an object.  The second group of users are allowed unfettered ability to to change an object's ACL.  Because of these two groups, we can't use type to distinguish admin users from normal. 

Looking over the allowed fields in a general query, there doesn't appear to be any sort of mapping from user to group, so it appears a general query cannot be used to find the set of users in a group.  Did I miss something?

Cheers,

Tony

[Conway, Mike]

Hi Tony, here's how Jargon's UserGroup service lists users in a given group 

select USER_ZONE,USER_NAME,USER_ID,USER_TYPE,USER_INFO,USER_COMMENT,USER_CREATE_TIME,USER_MODIFY_TIME,USER_GROUP_NAME where USER_GROUP_NAME = 'testListUserGroupMembersGroupExists'

GenQuery will compute the joins for you based on the selects, which can be tricky at times!

MC

---------------------

Mike Conway

Interface and Java API/Integration Developer  – DICE

www.irods.org

skype:michael.c.conway

LinkedIn: http://www.linkedin.com/pub/mike-conway/5/78a/231