On 08/13/2015 03:46 PM, Fraser Tweedale wrote:
On Thu, Aug 13, 2015 at 12:30:10PM +0300, Alexander Bokovoy wrote:
On Thu, 13 Aug 2015, Fraser Tweedale wrote:
On Thu, Aug 13, 2015 at 11:04:42AM +0200, Petr Vobornik wrote:
On 08/13/2015 05:28 AM, Fraser Tweedale wrote:
On Wed, Aug 12, 2015 at 02:56:54PM +0200, Petr Vobornik wrote:
usercertificate attr was moved from "System Modify Users" to this
new permission.


Note: hosts have permission "System: Manage Host Certificates", services
don't have it but usercertificate is in "System: Modify Services". I would
move it as well if usercertificate was not the only attr in "System: Modify

New permission works as expected.

What are the implications of removing userCertificate attribute from
"Modify Users" ACI?  Users could be relying on it given that there
is (until now) no more fine-grained permission.
I'm not sure what is the expected ACI upgrade behavior but applying this
patch on installed server and running ipa-server-upgrade ends with
userCertificate still in "System: Modify Users" permission - it eliminates
your worry. The rest of users who still run IPA < 4.2 won't even notice.

Ah, I see.

This raises a different problem: different ACIs on different
deployments, depending on when IPA was installed.  Unless I am
misunderstanding something, isn't that an undesirable situation?
We have precedent of upgrading ACIs via upgrade plugins.
So this is something we need to design for and execute.

If we've done it before and the consensus is that it's a problem for
another day, then I suppose it's an ACK from me.


Pushed to:
master: 6b978d74ae36f377c2d4f2cae860ca79b102e3c0
ipa-4-2: 7a509980d24b2bd445633026e64db48bb4203ba0

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to