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?
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
> 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
> -- > "iRODS: the Integrated Rule-Oriented Data-management System; A > community driven, open source, data grid software solution" > https://www.irods.org
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,
> 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
> Tony Edgin wrote:
>> 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
>> -- >> "iRODS: the Integrated Rule-Oriented Data-management System; A community driven, open source, data grid software solution" https://www.irods.org
> -- > "iRODS: the Integrated Rule-Oriented Data-management System; A community driven, open source, data grid software solution" https://www.irods.org
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
From: Antoine de Torcy <adeto...@email.unc.edu<mailto:adeto...@email.unc.edu>>
Reply-To: "irod-chat@googlegroups.com<mailto:irod-chat@googlegroups.com>" <irod-chat@googlegroups.com<mailto:irod-chat@googlegroups.com>>
Date: Wednesday, July 4, 2012 1:18 PM
To: "irod-chat@googlegroups.com<mailto:irod-chat@googlegroups.com>" <irod-chat@googlegroups.com<mailto:irod-chat@googlegroups.com>>
Cc: Tony Edgin <tedgin.ipl...@gmail.com<mailto:tedgin.ipl...@gmail.com>>
Subject: Re: [iROD-Chat:8305] Looking up a user's group membership from a rule
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
--
"iRODS: the Integrated Rule-Oriented Data-management System; A community driven, open source, data grid software solution" https://www.irods.org
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:
> 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
> From: Antoine de Torcy <adeto...@email.unc.edu>
> Reply-To: "irod-chat@googlegroups.com" <irod-chat@googlegroups.com>
> Date: Wednesday, July 4, 2012 1:18 PM
> To: "irod-chat@googlegroups.com" <irod-chat@googlegroups.com>
> Cc: Tony Edgin <tedgin.ipl...@gmail.com>
> Subject: Re: [iROD-Chat:8305] Looking up a user's group membership from a rule
> 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
> -- > "iRODS: the Integrated Rule-Oriented Data-management System; A community driven, open source, data grid software solution" https://www.irods.org
> -- > "iRODS: the Integrated Rule-Oriented Data-management System; A community driven, open source, data grid software solution" https://www.irods.org
> 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
> On Jun 28, 2012, at 4:59 AM, Jean-Yves Nief wrote:
>> 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
>> Tony Edgin wrote:
>>> 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
>>> -- >>> "iRODS: the Integrated Rule-Oriented Data-management System; A community driven, open source, data grid software solution" https://www.irods.org
>> -- >> "iRODS: the Integrated Rule-Oriented Data-management System; A community driven, open source, data grid software solution" https://www.irods.org
>> 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
>> On Jun 28, 2012, at 4:59 AM, Jean-Yves Nief wrote:
>>> 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
>>> Tony Edgin wrote:
>>>> 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
>>>> -- >>>> "iRODS: the Integrated Rule-Oriented Data-management System; A community driven, open source, data grid software solution" https://www.irods.org
>>> -- >>> "iRODS: the Integrated Rule-Oriented Data-management System; A community driven, open source, data grid software solution" https://www.irods.org
> -- > "iRODS: the Integrated Rule-Oriented Data-management System; A community driven, open source, data grid software solution" https://www.irods.org
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 <adeto...@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
> On Jul 5, 2012, at 8:32 AM, Jean-Yves Nief wrote:
> > 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
> >> On Jun 28, 2012, at 4:59 AM, Jean-Yves Nief wrote:
> >>> 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
> >>> Tony Edgin wrote:
> >>>> 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
> >>>> --
> >>>> "iRODS: the Integrated Rule-Oriented Data-management System; A
> community driven, open source, data grid software solution"
> https://www.irods.org
> >>> --
> >>> "iRODS: the Integrated Rule-Oriented Data-management System; A
> community driven, open source, data grid software solution"
> https://www.irods.org
> > --
> > "iRODS: the Integrated Rule-Oriented Data-management System; A community
> driven, open source, data grid software solution" https://www.irods.org
> --
> "iRODS: the Integrated Rule-Oriented Data-management System; A community
> driven, open source, data grid software solution" https://www.irods.org
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.
On Mon, Jul 9, 2012 at 3:29 PM, Tony Edgin <tedgin.ipl...@gmail.com> wrote:
> 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.
> 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 <adeto...@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
>> On Jul 5, 2012, at 8:32 AM, Jean-Yves Nief wrote:
>> > 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
>> >> On Jun 28, 2012, at 4:59 AM, Jean-Yves Nief wrote:
>> >>> 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
>> >>> Tony Edgin wrote:
>> >>>> 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
>> >>>> --
>> >>>> "iRODS: the Integrated Rule-Oriented Data-management System; A
>> community driven, open source, data grid software solution"
>> https://www.irods.org
>> >>> --
>> >>> "iRODS: the Integrated Rule-Oriented Data-management System; A
>> community driven, open source, data grid software solution"
>> https://www.irods.org
>> > --
>> > "iRODS: the Integrated Rule-Oriented Data-management System; A
>> community driven, open source, data grid software solution"
>> https://www.irods.org
>> --
>> "iRODS: the Integrated Rule-Oriented Data-management System; A community
>> driven, open source, data grid software solution" https://www.irods.org
> --
> "iRODS: the Integrated Rule-Oriented Data-management System; A community
> driven, open source, data grid software solution" https://www.irods.org
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?
On Wed, Jul 11, 2012 at 12:49 PM, Hao Xu <x...@cs.unc.edu> wrote:
> 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
> On Mon, Jul 9, 2012 at 3:29 PM, Tony Edgin <tedgin.ipl...@gmail.com>wrote:
>> 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.
>> 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 <adeto...@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
>>> On Jul 5, 2012, at 8:32 AM, Jean-Yves Nief wrote:
>>> > 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
>>> >> On Jun 28, 2012, at 4:59 AM, Jean-Yves Nief wrote:
>>> >>> 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
>>> >>> Tony Edgin wrote:
>>> >>>> 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
>>> >>>> --
>>> >>>> "iRODS: the Integrated Rule-Oriented Data-management System; A
>>> community driven, open source, data grid software solution"
>>> https://www.irods.org
>>> >>> --
>>> >>> "iRODS: the Integrated Rule-Oriented Data-management System; A
>>> community driven, open source, data grid software solution"
>>> https://www.irods.org
>>> > --
>>> > "iRODS: the Integrated Rule-Oriented Data-management System; A
>>> community driven, open source, data grid software solution"
>>> https://www.irods.org
>>> --
>>> "iRODS: the Integrated Rule-Oriented Data-management System; A community
>>> driven, open source, data grid software solution"
>>> https://www.irods.org
>> --
>> "iRODS: the Integrated Rule-Oriented Data-management System; A community
>> driven, open source, data grid software solution" https://www.irods.org
> --
> "iRODS: the Integrated Rule-Oriented Data-management System; A community
> driven, open source, data grid software solution" https://www.irods.org
From: Tony Edgin <tedgin.ipl...@gmail.com<mailto:tedgin.ipl...@gmail.com>>
Reply-To: <irod-chat@googlegroups.com<mailto:irod-chat@googlegroups.com>>
Date: Wed, 11 Jul 2012 17:35:02 -0700
To: <irod-chat@googlegroups.com<mailto:irod-chat@googlegroups.com>>
Subject: Re: [iROD-Chat:8337] Looking up a user's group membership from a rule
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
On Wed, Jul 11, 2012 at 12:49 PM, Hao Xu <x...@cs.unc.edu<mailto:x...@cs.unc.edu>> wrote:
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
On Mon, Jul 9, 2012 at 3:29 PM, Tony Edgin <tedgin.ipl...@gmail.com<mailto:tedgin.ipl...@gmail.com>> wrote:
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 <adeto...@email.unc.edu<mailto:adeto...@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.
>> 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<http://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
>> On Jun 28, 2012, at 4:59 AM, Jean-Yves Nief wrote:
>>> 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
>>> Tony Edgin wrote:
>>>> 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
>>>> --
>>>> "iRODS: the Integrated Rule-Oriented Data-management System; A community driven, open source, data grid software solution" https://www.irods.org
>>> --
>>> "iRODS: the Integrated Rule-Oriented Data-management System; A community driven, open source, data grid software solution" https://www.irods.org
> --
> "iRODS: the Integrated Rule-Oriented Data-management System; A community driven, open source, data grid software solution" https://www.irods.org
