Question: should a rodsuser see the protected metadata atr(s) val(s)?

[mstfdkmn]

I'm running iRODS 4.2.10 on CentOS 7. The plugin is 4.2.10.1 Release

A rodsadmin specifies guarded metadata attributes and values:

-bash-4.2$ imeta set -C /tempZone irods::metadata_guard '{"prefixes": ["rule::"], "admin_only": true}'
-bash-4.2$ imeta add -C /tempZone irods::metadata_guard '{"prefixes": ["sensitive::"], "admin_only": true}'
-bash-4.2$ imeta add -C /tempZone irods::metadata_guard '{"prefixes": ["irods::"], "admin_only": true}'

A rodsuser can query all guarded metadata although it doesnt normally have right to make a catalog query for a collection that it has no access.

[mustafa@dev-u0137480 ~]$ imeta ls -C /tempZone
AVUs defined for collection /tempZone:
attribute: irods::metadata_guard
value: {"prefixes": ["irods::"], "admin_only": true}
units:
----
attribute: irods::metadata_guard
value: {"prefixes": ["rule::"], "admin_only": true}
units:
----
attribute: irods::metadata_guard
value: {"prefixes": ["sensitive::"], "admin_only": true}
units:

Strangely enough a rodsuser can also make db query for the zone collection:

[mustafa@dev-u0137480 ~]$ iquest "select META_COLL_ATTR_VALUE where COLL_NAME ='/tempZone'"
META_COLL_ATTR_VALUE = {"prefixes": ["irods::"], "admin_only": true}
------------------------------------------------------------
META_COLL_ATTR_VALUE = {"prefixes": ["rule::"], "admin_only": true}
------------------------------------------------------------
META_COLL_ATTR_VALUE = {"prefixes": ["sensitive::"], "admin_only": true}
------------------------------------------------------------

Although it doesnt have access right on /tempZone:

[mustafa@dev-u0137480 ~]$ ils -A /tempZone
/tempZone:
        ACL - g:public#tempZone:read object   rods#tempZone:own
        Inheritance - Disabled
  C- /tempZone/home

[trel]

This is correct, and working as designed (I think).

The metadata guard is guarding against manipulation/edits - not against visibility.

We can implement that separately (instrumenting the query PEPs), but by default, all metadata in the system is visible, as the initial iRODS design and use cases were around being a finding aid.

Happy to entertain counter-examples. Everyone's use cases and demands are unique.

[mstfdkmn]

But normally I guess a rodsuser (contrary to rodsadmin) cannot see attached metadata on an object (data obj/col) where it doesnt have access, right?

imeta ls -C /tempZone/home/someoneElse/col

At least it should see Error: Collection ... does not exist. I guess the zone collection (/zoneName) has exception here?

[korydraughn]

We noticed that the public group has read access on the zone collection.

If you remove g:public#tempZone:read object, can the rodsuser still see the metadata on /tempZone?

[mstfdkmn]

Once the read access of public group is removed, indeed the rodsuser cannot see anymore the metadata on the zone collection.

rodsusers receive:

AVUs defined for collection /tempZone:
Error: Collection tempZone does not exist.

Do you remember any specific important reason to keep the read access level to the group public on the zone collection?

[trel]

It allows a user to be able to traverse down from the root (/) and then the zone (/tempZone). But it is not required.