Plugin cannot be configured at any other collection rather than the root of the zone

[mstfdkmn]

We're running iRODS 4.2.10 on CentOS 7. The plugin is 4.2.10.1 Release

It seems the plugin doesn't work if it is configured at any other collection rather than the root of the zone collection. It is only adding metadata but not protecting based on set configuration.

An admin user who has 'write' access right is setting the following configuration at a group collection in order to guard metadata only under the scope of a group:

-bash-4.2$ imeta set -C /tempZone/home/groupA irods::metadata_guard '{"prefixes": ["rules::"], "admin_only": true}'
-bash-4.2$ imeta ls -C /tempZone/home/groupA
AVUs defined for collection /tempZone/home/groupA:
attribute: irods::metadata_guard
value: {"prefixes": ["rules::"], "admin_only": true}
units:

See an attached metadata:

[user1@dev-u0137480 ~]$ imeta ls -d test.txt
AVUs defined for dataObj /tempZone/home/groupA/test.txt:
attribute: rules::atr2
value: val2
units:

A rods user can modify it without any warnings:

[user1@dev-u0137480 ~]$ imeta rm -d test.txt rules::atr2 val2

[trel]

That does seem like a bug. We'll confirm/reproduce.

[korydraughn]

This behavior is expected.

The plugin requires that the JSON configuration be placed on the zone collection (e.g. /tempZone). It never checks any other collection for configuration.

[trel]

Oh? What is our rationale for that? We should document that reasoning.

[trel]

The documentation does say this:

"The Rule Engine Plugin config is set as metadata on the zone collection"

We will consider whether it is a useful addition (and its associated costs) to honor metadata on subcollections of a zone as well.

Upside so far...

• the attempted configuration above, would work as expected. These would presumably be aggregated as the REP walks 'up' the collection tree to the root, and then evaluated against the to-be-manipulated AVU to see whether it should be guarded. If the different layers conflict (with regard to admin_only or editors... we would need do define a clear winner... presumably the one lower, or 'closer', to the data object(?))

Downside...

• it would cost computational cycles, to retrieve and then compare against these guards. The penalty would be linear with the collection depth of the data object in the zone.

---

An alternative implementation would not aggregate, but rather 'replace' any defined guards from 'above'. This seems like it would be more work to administer, and possibly surprise users.

Are there other ways this could be handled? Are there additional use cases that would require one approach over the other?

[korydraughn]

Oh? What is our rationale for that? We should document that reasoning.

I'm pretty sure the rationale for it being on the zone collection is so that the configuration can be shared by many servers.

Thinking about this more, the plugin only needs to be configured on the provider since updates to metadata have to go through the provider. However, if all servers become providers in 4.4/5.0, then all public facing servers need the plugin.

[trel]

can be shared by many servers

i don't understand this point. these are logical collections... so already 'shared' in that sense?

if all servers become providers in 4.4/5.0, then all public facing servers need the plugin

well, more precisely, 'all servers configured as providers' (consider the HA scenario)... rather than 'all servers'.

but yes - point is made, perhaps only providers need this plugin active... we'll need to test that assertion.

[korydraughn]

can be shared by many servers

i don't understand this point. these are logical collections... so already 'shared' in that sense?

By placing the configuration on the zone collection, it keeps admins from duplicating the configuration in the plugin_specific_configuration stanza (which isn't supported).

It just means the admin can define the config once and any server with the plugin enabled will automatically begin to enforce the policy.

[trel]

Understood about the single source of truth.

But ... if we instead ... searched the catalog to find this truth in various places, and then stitched it together, it would be more flexible, but cost a little more time to compute.

I think we should keep this open to investigate further. Seems intuitive that this type of configuration/usage could/would work, like @mstfdkmn attempted in the OP.

[korydraughn]

Sure. You can avoid the stitching step altogether by expanding the design of the config on the zone collection. The only limitation would be the size of the metadata column.

[trel]

Oh, I see... we're protecting who can edit the config itself by keeping it on the /Zone (presumably only admins have write access 'up there')...

That's a pretty good reason to keep it top-level only. If we decide to keep it that way, we should update the docs to explain the 'why'... as clearly... I forgot.

[trel]

And yes, the limitation on the AVU size could also be mitigated by allowing multiple irods::metadata_guard AVUs on '/Zone'...