Metadata access Control

[Siva]

iRODS user guide lists all the policy enforcement points: https://docs.irods.org/4.1.3/manual/architecture/#dynamic-policy-enforcement-points - I don’t see one for reading metadata.

In particular, I am interested in enforcing access controls on metadata. Is there a way to do it  now and if not is it possible to get on the feature request list. Any pointers would be helpful on this .

-Siva

[Terrell Russell]

Hi Siva,

Similar to the last email I just sent - this is on the radar, but is future work.

  https://github.com/irods/irods/issues/1595

There are no permission wrappers in GenQuery at the moment, so permissions around metadata are not currently possible.

There is current work to replace the internals of GenQuery for more flexibility, but that is ongoing and still in support of the 5.0 major timeline.

The initial design of iRODS declared the assumption that all metadata is readable, as it was designed to be a finding aid.  If you need permissions around information, that information was assumed to be included in a dataObject, not in the metadata.

Thanks, please continue asking questions, and of course, join the conversation at GitHub for future visibility,

Terrell

--
--
"iRODS: the Integrated Rule-Oriented Data-management System; A community driven, open source, data grid software solution" https://www.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.
For more options, visit https://groups.google.com/d/optout.

[Wayne Schroeder]

Hello Siva, Terrell,

As Terrell pointed out, iRODS, as originally implemented and by default, had no access controls on meta-data.  But there was some optional access control on meta-data added sometime before 2.1 and updated on occasion, known as 'strict' mode.  Starting in 2.1 this is enabled by the administrator by changing a default rule in core.re from:
acAclPolicy { }
to
acAclPolicy {msiAclPolicy("STRICT");

In the strict mode there are access controls (SQL clauses added) on certain queries (general-query calls) via the genqAppendAccessCheck function in icatGeneralQuery.c.  This was useful to those sites that did not want to freely share even 'ils' type meta-data, and it seemed to work at least fairly well.  It added a bit of complexity to the ICAT code, but was fairly straight-forward in function. This still might be present in 4.x, altho I'm not sure.

There is some mention of this in the 2.1 release notes: http://wiki.irods.org/index.php/Release_Notes_2.1 .  There is also a description in the core.re file describing the acAclPolicy rule.  More documentation can probably be found if this is of interest to anyone.  Searching for 'strict' on wiki.irods.org finds some.  And searching irod-chat turns up more.

Hope that helps,

 - Wayne -

Wayne Schroeder
Co-Principal Developer & Product Manager iRODS 0.5 thru 3.3.1 (2006-2014),retired
Owner and Principal: Integrated Data Management Solutions, LLC (2014-)
i-data-mgmt.com

[Terrell Russell]

Note that StrictACL is on by default in 4.x (since May 2012).

It does restrict a bit of 'system metadata' and generally behaves more like a traditional Unix filesystem, but StrictACLs have no effect on the access or visibility of metadata stored in AVUs.

Terrell

[Wayne Schroeder]

Thanks for the clarification, Terrell.  To me, and perhaps many readers, 'metadata' means both system metadata and user-defined metadata (AVUs), so it's good to make it clear.  System metadata includes such things as create-time, modify-time, object name, size, checksum/hash, and owner, and so is also data about data. 

I had forgotten that 4.x had StrictACLs on by default.  In 3.3.1 and before, it was off by default and I think most sites left it off.  I'm not sure how most 4.x sites set it now.

But yes, having ACLs on AVUs is separate from the StrictACLs feature, and will require additional development.

Thanks,

 - Wayne -

[Venustiano]

Hi Terrell,

Is there any further progress regarding permissions around metadata?

Although storing sensitive metadata in a dataObject can be a temporal solution, it is not an optimal solution for the long term.  The dataObject approach involve (among other things) the design dataObject structures that can be different per iRODS user and tailor made searching facilities have to be implemented within iRODS. Additionally, this means that researchers have to invest time worrying about the technical requirements related to privacy regulations such as the GDPR and FAIR principles. As far as understand, minimizing such burden is one of the main iRODS promises.

Hopefully, the iRODS community will concur with the original request (posted by Siva in 2015).

Thanks

Venustiano

To unsubscribe from this group and stop receiving emails from it, send an email to irod...@googlegroups.com.

[Terrell Russell]

Hi Venustiano,

iRODS has not implemented any additional access controls on metadata since this initial conversation.

However, I believe the community has had some additional experience with writing PEP-driven code to prevent/allow certain users access to metadata.  If anyone has examples or snippets of logic they have used to implement ACLs on AVU metadata, I'd be happy to include a generic version in our policy examples repository:

   https://github.com/irods/irods_policy_examples

We're hoping to curate the policy patterns we see in the community and gather them in one place.

We've accumulated three so far:

 - automated_ingest_sync_to_destination_resource.py

 - irods_policy_asynchronous_replication.re

 - irods_policy_logical_quotas.re

Terrell

To unsubscribe from this group and stop receiving emails from it, send an email to irod-chat+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/irod-chat/30a0fd5c-61d1-4ec6-860d-33b647f3f045%40googlegroups.com.