irods / irods_rule_engine_plugin_logical_quotas

BSD 3-Clause "New" or "Revised" License
1 stars 9 forks source link

A specific `own` access is required for rodsadmins to monitor group collections #76

Closed mstfdkmn closed 3 weeks ago

mstfdkmn commented 1 year ago

In order to start monitoring group collections, a rodsadmin user needs to have an 'own' access on group collections. Being member of a group collection in question for rodsadmins is not enough. The 'own' permission should be specifically given on the target collection if it is a group collection. Otherwise we are getting errors below. I think this is against what is described below in quotation.

IMPORTANT NOTE: To invoke rules provided by the plugin, the only requirement is that the user be a rodsadmin. The rodsadmin user does not need permissions set on the target collection.

PS. If the target collections are users' home collections, then this works normal.

-bash-4.2$ ils -A /u0137480/home/group1
/u0137480/home/group1:
        ACL - g:group1#u0137480:own
        Inheritance - Disabled
-bash-4.2$ iadmin lg group1
Members of group group1:
rods#u0137480
-bash-4.2$ irule -r irods_rule_engine_plugin-irods_rule_language-instance 'logical_quotas_start_monitoring_collection("/u0137480/home/group1")' null ruleExecOut
remote addresses: 10.0.2.100 ERROR: rcExecMyRule error.  status = -1205000 RE_RUNTIME_ERROR
Level 0: cannot set metadata: Unknown error -818000
Level 1: DEBUG:

-bash-4.2$ ichmod own rods /u0137480/home/group1
-bash-4.2$ ils -A /u0137480/home/group1
/u0137480/home/group1:
        ACL - rods#u0137480:own   g:group1#u0137480:own
        Inheritance - Disabled
-bash-4.2$ irule -r irods_rule_engine_plugin-irods_rule_language-instance 'logical_quotas_start_monitoring_collection("/u0137480/home/group1")' null ruleExecOut
-bash-4.2$ imeta ls -C /u0137480/home/group1
AVUs defined for collection /u0137480/home/group1:
attribute: irods::logical_quotas::total_number_of_data_objects
value: 0
units:
----
attribute: irods::logical_quotas::total_size_in_bytes
value: 0
units:

This is tested both for 4.2.10 and 4.2.11.

korydraughn commented 1 year ago

Can you confirm that ShowCollAcls is defined as a specific query in your system?

You should have the following:

irods@kdd-ws:~$ iquest --sql ls | grep -A1 ShowCollAcls
ShowCollAcls
select distinct R_USER_MAIN.user_name, R_USER_MAIN.zone_name, R_TOKN_MAIN.token_name, R_USER_MAIN.user_type_name from R_USER_MAIN, R_TOKN_MAIN, R_OBJT_ACCESS, R_COLL_MAIN where R_OBJT_ACCESS.object_id = R_COLL_MAIN.coll_id AND R_COLL_MAIN.coll_name = ? AND R_TOKN_MAIN.token_namespace = 'access_type' AND R_USER_MAIN.user_id = R_OBJT_ACCESS.user_id AND R_OBJT_ACCESS.access_type_id =
R_TOKN_MAIN.token_id
mstfdkmn commented 1 year ago

Hi Kory,

Yes, seems it is defined.

-bash-4.2$ iquest --sql ls | grep -A1 ShowCollAcls
ShowCollAcls
select distinct R_USER_MAIN.user_name, R_USER_MAIN.zone_name, R_TOKN_MAIN.token_name, R_USER_MAIN.user_type_name from R_USER_MAIN, R_TOKN_MAIN, R_OBJT_ACCESS, R_COLL_MAIN where R_OBJT_ACCESS.object_id = R_COLL_MAIN.coll_id AND R_COLL_MAIN.coll_name = ? AND R_TOKN_MAIN.token_namespace = 'access_type' AND R_USER_MAIN.user_id = R_OBJT_ACCESS.user_id AND R_OBJT_ACCESS.access_type_id = R_TOKN_MAIN.token_id
korydraughn commented 1 year ago

We'll investigate.

mstfdkmn commented 1 year ago

Hi Kory, I am not sure whether it is related to the issue here but if we create a sub-collestion like /tempZone/home/user1/coll_A as user1 and give own access to user2 , and finally revoke own access of user1, then we can encounter the same issue explained above. Meaning the rodsadmin user has to have a own access in this case to monitor the coll_A.

[user1@dev-u0137480 ~]$ ichmod own user2 collection_A
[user1@dev-u0137480 ~]$ ichmod null user1 collection_A

a query of the rodsadmin:

-bash-4.2$ iquest "select COLL_OWNER_NAME where COLL_NAME = '/u0137480/home/user1/collection_A'"
COLL_OWNER_NAME = user1
------------------------------------------------------------
-bash-4.2$ ils -A /u0137480/home/user1/collection_A
/u0137480/home/user1/collection_A:
        ACL - user2#u0137480:own
        Inheritance - Disabled

So I am confused a bit with https://github.com/irods/irods_rule_engine_plugin_logical_quotas/blob/main/src/handler.cpp#L159-L168 and existing ACLs on a given collection.

trel commented 1 year ago

The COLL_OWNER_NAME is the original owner name - not actually related to the ACLs that are granted.

It's a loophole/feature that we're working to clarify with https://github.com/irods/irods/issues/6579 and https://github.com/irods/irods/issues/6596

korydraughn commented 1 year ago

I believe this issue will be resolved by the work in #85.

korydraughn commented 3 weeks ago

This issue was resolved by #85.

The query involving COLL_OWNER_NAME is no longer used.

I've included the results produced by 4.2.12.0 below.

$ iadmin mkgroup g1
$ imkdir col.g
$ ichmod own g1 col.g
$ ichmod null rods col.g
$ ils -A col.g
/tempZone/home/rods/col.g:
        ACL - g:g1#tempZone:own   
        Inheritance - Disabled
$ irule -r irods_rule_engine_plugin-logical_quotas-instance '{"operation": "logical_quotas_start_monitoring_collection", "collection": "/tempZone/home/rods/col.g"}' null ruleExecOut

We'll add a test for this.