rodsadmin group own permission prevents collection monitoring

[tedgin]

• [x] main

• [x] 4-2-stable

  I'm running iRODS 4.2.8 on CentOS 7.

When the rodsadmin group has own permission on a collection, usage monitoring on that collection cannot be started due to an access permission error. The rodsadmin group permissions should not prevent collection monitoring.

Here's an example. The rodsadmi group has own permission on the coge user's home collection.

[irods@ds-dev-ies ~]$ ils -A /cyverse.dev/home/coge
/cyverse.dev/home/coge:
        ACL - coge#cyverse.dev:own   g:rodsadmin#cyverse.dev:own   
        Inheritance - Disabled

When as a rodsadmin type user I attempt to start monitoring this collection, I get a -818000, no access permission error.

[irods@ds-dev-ies ~]$ irule -r irods_rule_engine_plugin-irods_rule_language-instance "logical_quotas_start_monitoring_collection('/cyverse.dev/home/coge')" null ruleExecOut
remote addresses: 128.196.65.86 ERROR: rcExecMyRule error.  status = -1205000 RE_RUNTIME_ERROR
Level 0: cannot set metadata: Unknown error -818000
Level 1: DEBUG: 

If I remove rodadmin group permission from the collection, I can start monitoring it.

[irods@ds-dev-ies ~]$ ichmod -M null rodsadmin /cyverse.dev/home/coge
[irods@ds-dev-ies ~]$ irule -r irods_rule_engine_plugin-irods_rule_language-instance "logical_quotas_start_monitoring_collection('/cyverse.dev/home/coge')" null ruleExecOut
[irods@ds-dev-ies ~]$ imeta ls -C /cyverse.dev/home/coge
AVUs defined for collection /cyverse.dev/home/coge:
attribute: irods::logical_quotas::total_number_of_data_objects
value: 0
units: 
----
attribute: irods::logical_quotas::total_size_in_bytes
value: 0
units: 

[trel]

That definitely looks like a bug. Can you share the rodsLog entries when that occurs?

[trel]

And we'll want to confirm/deny it reproduces on 4.2.10 / 4-2-stable.

[tedgin]

Here's the log entries related to the failure.

Nov  4 14:57:07 pid:22721 NOTICE: rsModAVUMetadata: rcModAVUMetadata failed
Nov  4 14:57:07 pid:22721 remote addresses: 128.196.65.101, 128.196.65.86 ERROR: cannot set metadata: Unknown error -818000
Nov  4 14:57:07 pid:22721 remote addresses: 128.196.65.101, 128.196.65.86 ERROR: executeRuleAction Failed for logical_quotas_start_monitoring_collection status = -1205000 RE_RUNTIME_ERROR
Nov  4 14:57:07 pid:22721 NOTICE: executeRuleBody: Microservice or Action logical_quotas_start_monitoring_collection Failed with status -1205000
Nov  4 14:57:07 pid:22721 NOTICE: execRuleNodeRes: applyRule Failed: rule with status -1205000
Nov  4 14:57:07 pid:22721 DEBUG: 
Nov  4 14:57:07 pid:22721 NOTICE: execMyRule @external rule { logical_quotas_start_monitoring_collection('/cyverse.dev/home/coge') } Failed with status -1205000
Nov  4 14:57:07 pid:22721 remote addresses: 128.196.65.101, 128.196.65.86 ERROR: rsExecMyRule : -1205000, [-]   /irods_git_repo/plugins/rule_engines/irods_rule_engine_plugin-irods_rule_language/libirods_rule_engine_plugin-irods_rule_language.cpp:391:irods::error exec_rule_text(irods::default_re_ctx &, const std::string &, msParamArray_t *, const std::string &, irods::callback) :  status [RE_RUNTIME_ERROR]  errno [] -- message [execMyRule failed for rule @external rule { logical_quotas_start_monitoring_collection('/cyverse.dev/home/coge') }]

[tedgin]

It appears that the workaround is to temporarily remove rodsadmin permission when starting monitoring. Usage tracking itself seems to work when this group has permission on a collection.

-bash-4.2$ ichmod -M null rodsadmin .
-bash-4.2$ irule -r irods_rule_engine_plugin-irods_rule_language-instance "logical_quotas_start_monitoring_collection('/tempZone/home/rods')" null ruleExecOut
-bash-4.2$ ichmod -M own rodsadmin .
-bash-4.2$ imeta ls -C .
AVUs defined for collection /tempZone/home/rods:
attribute: irods::logical_quotas::total_number_of_data_objects
value: 1
units: 
----
attribute: irods::logical_quotas::total_size_in_bytes
value: 224
units: 
-bash-4.2$ iput irodsctl
-bash-4.2$ imeta ls -C .
AVUs defined for collection /tempZone/home/rods:
attribute: irods::logical_quotas::total_number_of_data_objects
value: 2
units: 
----
attribute: irods::logical_quotas::total_size_in_bytes
value: 507
units: 

[trel]

I bet this is related...

https://github.com/irods/irods_rule_engine_plugin_metadata_guard/issues/25

[trel]

Hmm, maybe not.

[korydraughn]

I've reproduced this on Ubuntu 16 and iRODS 4.2.10.

[korydraughn]

This bug is due to the plugin attempting to become a user called rodsadmin which isn't allowed because it's a group. The fix is to become the original owner of the collection before invoking metadata operations.

@tedgin Is the use of the rodsadmin group just for example purposes? You aren't expecting members of that group to be treated as admins are you?

[trel]

We've created https://github.com/irods/irods/issues/6063 to reduce this confusion/collision for new installs.

[tedgin]

I don't expect members of the group rodsadmin to be treated as rodsadmin type users, although historically that was the the case. All rodsadmin type users belonged to this group. By giving this group access to a data object or collection, you allowed any rodsadmin type user to access it without each admin user having to grant themself access before accessing. I guess it decluttered the output of ils -A too. I don't see much value in the group as it was intended to be used. We use it slightly differently. Certain highly trusted services like the DE are given accounts that belong to the rodsadmin group. Our rule logic ensures that the rodsadmin group has own permission on everything. This allows these services to have unfettered access to user data.

[trel]

"historically that was the case"

Is this true? Did changing a rodsuser to rodsadmin (or creating a new rodsadmin user) put them in the rodsadmin group automatically?

If true, we need to go chase down that code...

[tedgin]

I''m not certain. Browsing irods-chat, it appears that as far back as iRODS 2.2, users had to be manually added to rodsadmin group. See https://groups.google.com/g/irod-chat/c/kyAXbSWPtJs/m/RN4gc4B_Fg0J.

[trel]

Got it - thanks for the link.

I don't think it's helpful to have a rodsadmin group at all. Confusing at best, misleading/damaging at worst.