scanner returning users without enough permission to modify metadata

[trel]

When the scanner is querying for users to run the rule to assign the metadata to queue a data object for movement...

It is just returning the first user in the list, even if the user does not have write permission or greater on the data object that needs to have its AVU modified.

A workaround is to assign a query to the resource...

-bash-4.2$ imeta set -R <resc> irods::storage_tiering::query "SELECT DATA_NAME, COLL_NAME, DATA_OWNER_NAME, DATA_REPL_NUM WHERE META_DATA_ATTR_NAME = 'irods::access_time' AND META_DATA_ATTR_VALUE < 'TIME_CHECK_STRING' AND DATA_RESC_ID IN ('1400514')"

This works, but uses DATA_OWNER_NAME, which is the original uploader, who may no longer have permissions in the ACLs on the data object.

A better way would be to ask for users who have enough permissions (greater than or equal to modify object).

-bash-4.2$ imeta set -R <resc> irods::storage_tiering::query "SELECT DATA_NAME, COLL_NAME, USER_NAME, DATA_REPL_NUM WHERE META_DATA_ATTR_NAME = 'irods::access_time' AND META_DATA_ATTR_VALUE < '9999999999999' AND DATA_RESC_ID IN ('1400514') AND DATA_ACCESS_TYPE >= '1120'"

This returns users who have ACLs on the objects, who also have modify_object permission or greater (own).

[korydraughn]

With 4.2.12, this can be resolved by connecting as the local rodsadmin user and using admin level privileges to modify metadata.

This solution doesn't require any modifications to queries, etc. This solution is also used in the logical quotas implementation.

We need to be careful of where the connection is made, else we can end up creating and tearing down connections frequently (i.e do not establish the connection in a loop).