Rename/Move and Metadata Permissions in iRODS 5.0.1

[Laura Lo Gerfo]

Dear iRODS Consortium,

I am writing to better understand the permission requirements for rename/move operations and metadata modifications in iRODS 5.0.1.

From our testing, we have observed the following:

- Rename/move operations appear to require ownership  (as noted in GitHub issue https://github.com/irods/irods/issues/6400). This prevents users with standard permissions from renaming objects or collections.
- Metadata (AVU) modifications require elevated privileges (modify_object).

We are developing a web application in which users can create collections, upload files, and manage their own data. In this context, requiring “own” permission for simple operations such as renaming is a significant limitation, as granting ownership also allows ACL modification, which is not always desirable.

We would appreciate your guidance on the following:

- Are there recommended patterns or best practices to enable safe rename/move operations without granting full ownership?
- Are there any plans or a tentative timeline to address or improve this behavior for both rename/move operations and metadata modifications?

 

These aspects have a strong impact on our application design.

 

Best regards,
Laura

[Terrell Russell]

Hi Laura,

Yes, separating the permissions more granularly is still in the future.  It's slated for 6.0.0 at the moment since we have to be very careful about changing how permissions work for existing deployments.

I think your best bet at the moment is to add some policy around the chmod operation (limiting ability for an owner to modify an ACL).

If you want to deny the chmod operation for a list of known users...

pep_api_mod_access_control_pre(*INST, *COMM, *MODACCESSCONTROLINP) {
  *requesting_user = *COMM.user_user_name
  *target_user = *MODACCESSCONTROLINP.user_name
  *logical_path = *MODACCESSCONTROLINP."path"
  *denylist = list('alice', 'bobby');
  *denied = 0;
  foreach (*u in *denylist) {
    if (*u == *requesting_user) {
      writeLine('serverLog','DENIED chmod by [*requesting_user] for [*target_user] on [*logical_path]');
      *denied = 1;
    }
  }
  if (*denied == 1){ SYS_NOT_ALLOWED };
}

If you want to disallow any non-admin user, you could use...

pep_api_mod_access_control_pre(*INST, *COMM, *MODACCESSCONTROLINP) {
  *requesting_user = *COMM.user_user_name
  *target_user = *MODACCESSCONTROLINP.user_name
  *logical_path = *MODACCESSCONTROLINP."path"
  foreach(*row in SELECT USER_TYPE where USER_NAME = '*requesting_user') {
    *user_type = *row.USER_TYPE;
  }
  if ("rodsadmin" != *user_type) {
    writeLine('serverLog','DENIED chmod by [*requesting_user] for [*target_user] on [*logical_path]');
    SYS_NOT_ALLOWED;
  }

}

I hope that helps you design what you are looking for.

 

Terrell

--
--
The Integrated Rule-Oriented Data System (iRODS) - https://irods.org
 
iROD-Chat: http://groups.google.com/group/iROD-Chat
---
You received this message because you are subscribed to the Google Groups "iRODS-Chat" group.
To unsubscribe from this group and stop receiving emails from it, send an email to irod-chat+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/irod-chat/15768a09-4369-4db2-be16-6a3ec2d12bb4n%40googlegroups.com.

[Laura Lo Gerfo]

Dear Terrell,

thank you for your suggestions.

Unfortunately, the deny list approach is not feasible for us. Our setup relies on duplicated groups (owners/users per research line), where owners can also manage permissions with fine granularity. This would make deny lists complex and hard to maintain. For similar reasons, restricting the ability to manage permissions would also not work well in our case, as it would interfere with operations that our group owners need to perform.

The only viable option we see is to use a service account with admin privileges to perform rename operations on behalf of users, with appropriate checks at the permissions level.

Do you see any drawbacks with this approach, or would you recommend an alternative?

Best regards,
Laura

To view this discussion visit https://groups.google.com/d/msgid/irod-chat/CAFaqteY0%3DPK-VpwbZN7%3DfOiLwS14-y79ke6Op7vuwm1PdSvhwQ%40mail.gmail.com.

[mustafa dikmen]

Dear,

I guess another way to go could be to catch the rename request on the server, give the user the permissions they need, and then just switch them back once the move/rename is finished. You'll need to have PRC installed on the server, and you can use the rods user in the PEPs like below. 

acl_own = iRODSAccess("own", obj_path, username, zone)
session.acls.set(acl_own, admin=True)

old_acl = iRODSAccess("old_permission", obj_path, username, zone)
session.acls.set(null_acl, admin=True)

def pep_api_data_obj_rename_pre/post(rule_args, callback, rei)

Best Regards,

Mustafa

To view this discussion visit https://groups.google.com/d/msgid/irod-chat/VI1PR06MB892718E7187D77D86E047771822D2%40VI1PR06MB8927.eurprd06.prod.outlook.com.

[Terrell Russell]

> The only viable option we see is to use a service account with admin privileges to perform rename operations on behalf of users, with appropriate checks at the permissions level.

I think that sounds reasonable, yes.

It would be interesting to see your requirements, along with the solution, once you get it working as needed.

Terrell

To view this discussion visit https://groups.google.com/d/msgid/irod-chat/CAKCrKVi3gtY8xzkgadfiNrQRVuYhBTn2A6ME8dvaWy_0oc91qg%40mail.gmail.com.

[Laura Lo Gerfo]

Dear Terrell, Mustafa, all,

 

Thank you for the feedback and suggestions.

 

I have implemented the solution suggested by Mustafa, taking care to avoid leaving any temporary permissions in place after the operation completes.

 

This approach looks promising for our use case until a definitive fix is available, because by isolating the logic in the iRODS rules, we can support rename/move operations not only from our web UI, but also from other iRODS clients.

 

Many thanks to everyone for the useful discussion.

To view this discussion visit https://groups.google.com/d/msgid/irod-chat/CAFaqteYcmp2ff0JHdjyVFCAMowK-PDO1501EwDuNP0L%3D3R_Ckg%40mail.gmail.com.