[Freeipa-devel] [PATCH] 916 vault: add vault container commands

[Simo Sorce]

On Tue, 2015-09-01 at 17:15 +0200, Petr Vobornik wrote:
> On 09/01/2015 04:39 PM, Jan Cholasta wrote:
> > On 1.9.2015 16:26, Jan Cholasta wrote:
> >> On 26.8.2015 13:22, Petr Vobornik wrote:
> >>> On 08/25/2015 08:04 PM, Petr Vobornik wrote:
> >>>> adds commands:
> >>>> * vaultcontainer-show [--service <service>|--user <user> ]
> >>>> * vaultcontainer-add-owner
> >>>>       [--service <service>|--user <user> ]
> >>>>       [--users <users>]  [--groups <groups>] [--services <services>]
> >>>> * vaultcontainer-remove-owner
> >>>>       [--service <service>|--user <user> ]
> >>>>       [--users <users>]  [--groups <groups>] [--services <services>]
> >>>>
> >>>> https://fedorahosted.org/freeipa/ticket/5250
> >>>>
> >>>> Use cases:
> >>>> 1. When user/service is deleted, associated vault container looses
> >>>> owner. There was no API command to set the owner.
> >>>> 2. Change owner of container by admin to manage access.
> >>>>
> >>>> Show command was added to show current owners.
> >>>>
> >>>> Find command was not added, should it be?
> >>>>
> >>>>
> >>>
> >>> There is also a design for vault container ownership handling created by
> >>> Endi - it's for future Vault 2.0.
> >>>
> >>> http://www.freeipa.org/page/V4/Password_Vault_2.0#Adding_container_owner
> >>>
> >>> This patch has a different API than the proposed - different way of
> >>> specifying the container. The design page uses path e.g. /users/foobar.
> >>> This patch uses the same way as vaults e.g. --user=foobar. This means
> >>> that the implementation in this patch cannot manage ownership of parent
> >>> vault containers e.g. cn=users,cn=vaults,cn=kra,$SUFFIX.
> >>>
> >>> Do we want to go with this approach in 4.2?
> >>>
> >>> Attaching also new path which removes setting of owner which doesn't
> >>> exist so that integrity is OK and that it is consistent with removing of
> >>> user.
> >>>
> >>> Updated patch attached - output fix.
> >>
> >> We had a long discussion about this with Petr and we think the best
> >> approach is as follows:
> >>
> >>    * Add new "Vault administrators" privilege. Vault administrators will
> >> have unrestricted access to vaults and vault containers, including the
> >> power to add/remove owners of vaults and vault containers.
> >>
> >>    * Remove the ability of vault owners to add/remove other vault
> >> owners. If vault owner needs to be changed, vault administrator has to
> >> do it. Note that vault owners will still have the ability to add/remove
> >> vault members.
> >>
> >>    * When adding new vault container, set owner to the current user. If
> >> vault container owner needs to be changed, vault administrator has to do
> >> it.
> >>
> >>    * Allow adding vaults and vault containers only if the owner is set
> >> to the current user.
> >>
> >>    * Introduce commands to modify vault container owner and to delete
> >> vault container, so the administrator has a choice between assigning
> >> ownership or deleting an unowned container.
> >
> > Also:
> >
> >    * Control access to vault data using an ipaProtectedOperation ACI.
> > Users which have read access to "ipaProtectedOperation;accessKRA" on a
> > vault can retrieve data from the vault and users which have write access
> > to "ipaProtectedOperation;accessKRA" on a vault can archive data in the
> > vault.
> >
> > Honza
> >
> 
> +1
> 
> CCing Simo and Endi to check the proposal.
> 
> And Scott (related to #5216, #5215)

Sounds reasonable to me.
I can see that allowing owners to hand over vaults w/o admin
intervention may have some appeal in some use cases, but I also see it
can bring downsides with it, so all in all I think I agree with the
above points.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York