Closed mstfdkmn closed 3 weeks 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
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
We'll investigate.
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.
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
I believe this issue will be resolved by the work in #85.
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.
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.
PS. If the target collections are users' home collections, then this works normal.
This is tested both for 4.2.10 and 4.2.11.