Nowadays the user is allowed to modify memberOf attributes even if there is active memberOf plugin. It would be nice if memberOf plugin prevented direct modifications by user and throwed some meaningful error message.
E.g. Server is unwilling to perform + additional text "memberOf attributes are generated automatically. Modify member attributes."
no cloning, upstream tests can cover this.
Probably, we should extend this RFE to the other similar plug-ins such as automember, linkedattrs and MEP?
We should introduce a config parameter in each plug-in entry to allow client update or not?
Personally I do not see a reason to allow modifications or even make it configurable.
It could be possible to have it so that alteration of memberOf was equivalent to enrolling someone in a group if that group existed. However, this could get complicated very quickly.
I think no configuration is needed, unless some plan was created to allow updating in reverse on these plugins.
The biggest risk of this change is that we are intercepting more write operations than before, but the idea of the enhancement is sound.
Per triage, push the target milestone to 1.3.6.
So I have an idea for this, but it may not be the most "straight forward".
I want to propose that we have a second "aci" module that checks
if operation is internal || is Directory Manager: allow if attr in block_list: fail allow
So when a plugin like memberOf starts up, it would register an attribute (or set of) to the "blacklist" module. The blacklist module would then check every operation that is being made and if it sees a blacklisted attribute in the add / change, it would reject the operation.
This allows plugins to programatically update the list at startup / plugin enable (dynamic), and means admins can't tamper or configure aci's in a way that breaks the process.
This would probably need:
Metadata Update from @firstyear: - Issue assigned to firstyear - Issue set to the milestone: 1.3.6.0
Metadata Update from @mreynolds: - Custom field rhbz reset (from 0) - Issue set to the milestone: 1.4 backlog (was: 1.3.6.0)
Metadata Update from @mreynolds: - Custom field reviewstatus adjusted to None - Issue set to the milestone: 1.4.5 (was: 1.4 backlog)
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/894
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.