[Freeipa-devel] [PATCH] 910 add permission: System: Manage User Certificates

Fraser Tweedale ftweedal at redhat.com
Thu Aug 13 13:46:02 UTC 2015


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.
> >>>>
> >>>>https://fedorahosted.org/freeipa/ticket/5177
> >>>>
> >>>>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
> >>>>Services".
> >>>>
> >>>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.

Cheers,
Fraser




More information about the Freeipa-devel mailing list