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

Petr Vobornik pvoborni at redhat.com
Tue Sep 1 15:15:57 UTC 2015


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)
-- 
Petr Vobornik




More information about the Freeipa-devel mailing list