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.