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

[Jan Cholasta]

On 14.9.2015 09:44, Jan Cholasta wrote:

On 9.9.2015 18:39, Petr Vobornik wrote:

On 09/09/2015 10:52 AM, Jan Cholasta wrote:

On 8.9.2015 23:06, Petr Vobornik wrote:

On 09/03/2015 03:18 PM, Jan Cholasta wrote:

On 2.9.2015 07:26, Endi Sukma Dewata wrote:

On 9/1/2015 10:22 AM, Simo Sorce wrote:

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 |--user  ]
* vaultcontainer-add-owner
   [--service |--user  ]
   [--users ]  [--groups ] [--services
]
* vaultcontainer-remove-owner
   [--service |--user  ]
   [--users ]  [--groups ] [--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.



Not a total objection, but if many people in unrelated groups are
using
vaults, and they are sharing the vaults only with members of each
group,
having to ask a Vault Administrator for each ownership change
sounds a
bit cumbersome. Since the Vault Adminstrator will have access to all
vaults in all groups, only a small number of people can be trusted to
hold that role. If there are many ownership changes the Vault
Administrator will have to handle all those requests, and the vault
users may have to wait until the change is completed.

If owners are allowed to add others as owners, the vaults will be
pretty
much maintenance free to the admin.


Owners can still manage members, which is IMO good enough for
sharing a
vault with other users.



Regardless, please update the wiki page to describe the new behavior
when it's implemented:
http://www.freeipa.org/page/V4/Password_Vault_1.1


Sure.

I have updated and rebased Petr's patch 916.

Patch 488 obsoletes Petr's patch 918.

Patch for vault data access control is not included, because I was not
able to make GER work correctly with
"ipaProtectedOperation;accessKRA".



I found 1 major issue(#3), one easy fix(#2), optional(#1) and a
question
(#4).

1. `ipa vaultcontainer-del` doesn't show user/service name. IMHO not a
blocker.

[pvoborni@vm-063 ~]$ ipa vaultcontainer-del --user=fbar
--
Deleted vault container ""
--


Fixed.




2. Invalid description of vaultcontainer-show
   "Display information 

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

[Petr Vobornik]

On 09/17/2015 11:37 AM, Jan Cholasta wrote:

On 14.9.2015 09:44, Jan Cholasta wrote:

On 9.9.2015 18:39, Petr Vobornik wrote:

On 09/09/2015 10:52 AM, Jan Cholasta wrote:

On 8.9.2015 23:06, Petr Vobornik wrote:

On 09/03/2015 03:18 PM, Jan Cholasta wrote:

On 2.9.2015 07:26, Endi Sukma Dewata wrote:

On 9/1/2015 10:22 AM, Simo Sorce wrote:

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 |--user  ]
* vaultcontainer-add-owner
   [--service |--user  ]
   [--users ]  [--groups ] [--services
]
* vaultcontainer-remove-owner
   [--service |--user  ]
   [--users ]  [--groups ] [--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.



Not a total objection, but if many people in unrelated groups are
using
vaults, and they are sharing the vaults only with members of each
group,
having to ask a Vault Administrator for each ownership change
sounds a
bit cumbersome. Since the Vault Adminstrator will have access to all
vaults in all groups, only a small number of people can be
trusted to
hold that role. If there are many ownership changes the Vault
Administrator will have to handle all those requests, and the vault
users may have to wait until the change is completed.

If owners are allowed to add others as owners, the vaults will be
pretty
much maintenance free to the admin.


Owners can still manage members, which is IMO good enough for
sharing a
vault with other users.



Regardless, please update the wiki page to describe the new behavior
when it's implemented:
http://www.freeipa.org/page/V4/Password_Vault_1.1


Sure.

I have updated and rebased Petr's patch 916.

Patch 488 obsoletes Petr's patch 918.

Patch for vault data access control is not included, because I was
not
able to make GER work correctly with
"ipaProtectedOperation;accessKRA".



I found 1 major issue(#3), one easy fix(#2), optional(#1) and a
question
(#4).

1. `ipa vaultcontainer-del` doesn't show user/service name. IMHO not a
blocker.

[pvoborni@vm-063 ~]$ ipa vaultcontainer-del --user=fbar
--
Deleted vault container ""
--


Fixed.




2. Invalid description of 

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

[Jan Cholasta]

On 9.9.2015 18:39, Petr Vobornik wrote:

On 09/09/2015 10:52 AM, Jan Cholasta wrote:

On 8.9.2015 23:06, Petr Vobornik wrote:

On 09/03/2015 03:18 PM, Jan Cholasta wrote:

On 2.9.2015 07:26, Endi Sukma Dewata wrote:

On 9/1/2015 10:22 AM, Simo Sorce wrote:

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 |--user  ]
* vaultcontainer-add-owner
   [--service |--user  ]
   [--users ]  [--groups ] [--services
]
* vaultcontainer-remove-owner
   [--service |--user  ]
   [--users ]  [--groups ] [--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.



Not a total objection, but if many people in unrelated groups are
using
vaults, and they are sharing the vaults only with members of each
group,
having to ask a Vault Administrator for each ownership change sounds a
bit cumbersome. Since the Vault Adminstrator will have access to all
vaults in all groups, only a small number of people can be trusted to
hold that role. If there are many ownership changes the Vault
Administrator will have to handle all those requests, and the vault
users may have to wait until the change is completed.

If owners are allowed to add others as owners, the vaults will be
pretty
much maintenance free to the admin.


Owners can still manage members, which is IMO good enough for sharing a
vault with other users.



Regardless, please update the wiki page to describe the new behavior
when it's implemented:
http://www.freeipa.org/page/V4/Password_Vault_1.1


Sure.

I have updated and rebased Petr's patch 916.

Patch 488 obsoletes Petr's patch 918.

Patch for vault data access control is not included, because I was not
able to make GER work correctly with "ipaProtectedOperation;accessKRA".



I found 1 major issue(#3), one easy fix(#2), optional(#1) and a question
(#4).

1. `ipa vaultcontainer-del` doesn't show user/service name. IMHO not a
blocker.

[pvoborni@vm-063 ~]$ ipa vaultcontainer-del --user=fbar
--
Deleted vault container ""
--


Fixed.




2. Invalid description of vaultcontainer-show
   "Display information about a vault."


Fixed



3. Something which 

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

[Jan Cholasta]

On 8.9.2015 23:06, Petr Vobornik wrote:

On 09/03/2015 03:18 PM, Jan Cholasta wrote:

On 2.9.2015 07:26, Endi Sukma Dewata wrote:

On 9/1/2015 10:22 AM, Simo Sorce wrote:

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 |--user  ]
* vaultcontainer-add-owner
   [--service |--user  ]
   [--users ]  [--groups ] [--services
]
* vaultcontainer-remove-owner
   [--service |--user  ]
   [--users ]  [--groups ] [--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.



Not a total objection, but if many people in unrelated groups are using
vaults, and they are sharing the vaults only with members of each group,
having to ask a Vault Administrator for each ownership change sounds a
bit cumbersome. Since the Vault Adminstrator will have access to all
vaults in all groups, only a small number of people can be trusted to
hold that role. If there are many ownership changes the Vault
Administrator will have to handle all those requests, and the vault
users may have to wait until the change is completed.

If owners are allowed to add others as owners, the vaults will be pretty
much maintenance free to the admin.


Owners can still manage members, which is IMO good enough for sharing a
vault with other users.



Regardless, please update the wiki page to describe the new behavior
when it's implemented:
http://www.freeipa.org/page/V4/Password_Vault_1.1


Sure.

I have updated and rebased Petr's patch 916.

Patch 488 obsoletes Petr's patch 918.

Patch for vault data access control is not included, because I was not
able to make GER work correctly with "ipaProtectedOperation;accessKRA".



I found 1 major issue(#3), one easy fix(#2), optional(#1) and a question
(#4).

1. `ipa vaultcontainer-del` doesn't show user/service name. IMHO not a
blocker.

[pvoborni@vm-063 ~]$ ipa vaultcontainer-del --user=fbar
--
Deleted vault container ""
--


Fixed.




2. Invalid description of vaultcontainer-show
   "Display information about a vault."


Fixed.



3. Something which needs to be fixed:

Setting password for first vault without a vault container 

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

[Petr Vobornik]

On 09/09/2015 10:52 AM, Jan Cholasta wrote:

On 8.9.2015 23:06, Petr Vobornik wrote:

On 09/03/2015 03:18 PM, Jan Cholasta wrote:

On 2.9.2015 07:26, Endi Sukma Dewata wrote:

On 9/1/2015 10:22 AM, Simo Sorce wrote:

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 |--user  ]
* vaultcontainer-add-owner
   [--service |--user  ]
   [--users ]  [--groups ] [--services
]
* vaultcontainer-remove-owner
   [--service |--user  ]
   [--users ]  [--groups ] [--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.



Not a total objection, but if many people in unrelated groups are using
vaults, and they are sharing the vaults only with members of each
group,
having to ask a Vault Administrator for each ownership change sounds a
bit cumbersome. Since the Vault Adminstrator will have access to all
vaults in all groups, only a small number of people can be trusted to
hold that role. If there are many ownership changes the Vault
Administrator will have to handle all those requests, and the vault
users may have to wait until the change is completed.

If owners are allowed to add others as owners, the vaults will be
pretty
much maintenance free to the admin.


Owners can still manage members, which is IMO good enough for sharing a
vault with other users.



Regardless, please update the wiki page to describe the new behavior
when it's implemented:
http://www.freeipa.org/page/V4/Password_Vault_1.1


Sure.

I have updated and rebased Petr's patch 916.

Patch 488 obsoletes Petr's patch 918.

Patch for vault data access control is not included, because I was not
able to make GER work correctly with "ipaProtectedOperation;accessKRA".



I found 1 major issue(#3), one easy fix(#2), optional(#1) and a question
(#4).

1. `ipa vaultcontainer-del` doesn't show user/service name. IMHO not a
blocker.

[pvoborni@vm-063 ~]$ ipa vaultcontainer-del --user=fbar
--
Deleted vault container ""
--


Fixed.




2. Invalid description of vaultcontainer-show
   "Display information about a vault."


Fixed



3. Something which needs to be fixed:

Setting password for 

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

[Jan Cholasta]

On 2.9.2015 07:26, Endi Sukma Dewata wrote:

On 9/1/2015 10:22 AM, Simo Sorce wrote:

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 |--user  ]
* vaultcontainer-add-owner
   [--service |--user  ]
   [--users ]  [--groups ] [--services
]
* vaultcontainer-remove-owner
   [--service |--user  ]
   [--users ]  [--groups ] [--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.



Not a total objection, but if many people in unrelated groups are using
vaults, and they are sharing the vaults only with members of each group,
having to ask a Vault Administrator for each ownership change sounds a
bit cumbersome. Since the Vault Adminstrator will have access to all
vaults in all groups, only a small number of people can be trusted to
hold that role. If there are many ownership changes the Vault
Administrator will have to handle all those requests, and the vault
users may have to wait until the change is completed.

If owners are allowed to add others as owners, the vaults will be pretty
much maintenance free to the admin.


Owners can still manage members, which is IMO good enough for sharing a 
vault with other users.




Regardless, please update the wiki page to describe the new behavior
when it's implemented:
http://www.freeipa.org/page/V4/Password_Vault_1.1


Sure.

I have updated and rebased Petr's patch 916.

Patch 488 obsoletes Petr's patch 918.

Patch for vault data access control is not included, because I was not 
able to make GER work correctly with "ipaProtectedOperation;accessKRA".


--
Jan Cholasta
From d9a3cfa7cfcf4402f5d83a61d2a7745a71d8cca3 Mon Sep 17 00:00:00 2001
From: Petr Vobornik 
Date: Tue, 25 Aug 2015 19:56:00 +0200
Subject: [PATCH 1/4] vault: add vault container commands

adds commands:
* vaultcontainer-show [--service |--user |--shared ]
* vaultcontainer-del [--service |--user |--shared ]
* vaultcontainer-add-owner
 [--service |--user |--shared ]
 [--users ]  [--groups ] [--services ]
* vaultcontainer-remove-owner
 [--service |--user |--shared ]
 [--users ]  [--groups ] [--services ]

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

[Endi Sukma Dewata]

On 9/1/2015 10:22 AM, Simo Sorce wrote:

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 |--user  ]
* vaultcontainer-add-owner
   [--service |--user  ]
   [--users ]  [--groups ] [--services ]
* vaultcontainer-remove-owner
   [--service |--user  ]
   [--users ]  [--groups ] [--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.



Not a total objection, but if many people in unrelated groups are using 
vaults, and they are sharing the vaults only with members of each group, 
having to ask a Vault Administrator for each ownership change sounds a 
bit cumbersome. Since the Vault Adminstrator will have access to all 
vaults in all groups, only a small number of people can be trusted to 
hold that role. If there are many ownership changes the Vault 
Administrator will have to handle all those requests, and the vault 
users may have to wait until the change is completed.


If owners are allowed to add others as owners, the vaults will be pretty 
much maintenance free to the admin.


Regardless, please update the wiki page to describe the new behavior 
when it's implemented:

http://www.freeipa.org/page/V4/Password_Vault_1.1

--
Endi S. Dewata

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

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

[Jan Cholasta]

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 |--user  ]
* vaultcontainer-add-owner
  [--service |--user  ]
  [--users ]  [--groups ] [--services ]
* vaultcontainer-remove-owner
  [--service |--user  ]
  [--users ]  [--groups ] [--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

--
Jan Cholasta

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

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

[Jan Cholasta]

On 26.8.2015 13:22, Petr Vobornik wrote:

On 08/25/2015 08:04 PM, Petr Vobornik wrote:

adds commands:
* vaultcontainer-show [--service |--user  ]
* vaultcontainer-add-owner
  [--service |--user  ]
  [--users ]  [--groups ] [--services ]
* vaultcontainer-remove-owner
  [--service |--user  ]
  [--users ]  [--groups ] [--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.


Honza

--
Jan Cholasta

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

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

[Petr Vobornik]

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 |--user  ]
* vaultcontainer-add-owner
  [--service |--user  ]
  [--users ]  [--groups ] [--services ]
* vaultcontainer-remove-owner
  [--service |--user  ]
  [--users ]  [--groups ] [--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

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

Re: [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 |--user  ]
>  * vaultcontainer-add-owner
>    [--service |--user  ]
>    [--users ]  [--groups ] [--services ]
>  * vaultcontainer-remove-owner
>    [--service |--user  ]
>    [--users ]  [--groups ] [--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

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

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

[Petr Vobornik]

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.
--
Petr Vobornik
From 7ef2a5580f06103d803e2ec2e85315a40d5e8666 Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Wed, 26 Aug 2015 13:00:05 +0200
Subject: [PATCH] vault: set vaultcontainer owner only if exists

To be consistent with situation when owner(e.g. user) is deleted.

https://fedorahosted.org/freeipa/ticket/5250
---
 ipalib/plugins/vault.py | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/ipalib/plugins/vault.py b/ipalib/plugins/vault.py
index 0026ac11ed79c5aaf8de7d8ad13778284d00496b..da1a58cfb77932e8a907725eb88f9f5c6df023c9 100644
--- a/ipalib/plugins/vault.py
+++ b/ipalib/plugins/vault.py
@@ -422,6 +422,12 @@ class vault(LDAPObject):
 
 entries = []
 
+# check that owner exists
+try:
+self.backend.get_entry(owner_dn, [])
+except errors.NotFound:
+owner_dn = None
+
 while dn:
 assert dn.endswith(container_dn)
 
@@ -431,9 +437,11 @@ class vault(LDAPObject):
 {
 'objectclass': ['ipaVaultContainer'],
 'cn': rdn['cn'],
-'owner': [owner_dn],
 })
 
+if owner_dn:
+entry['owner'] = [owner_dn]
+
 # if entry can be added, return
 try:
 self.backend.add_entry(entry)
-- 
2.4.3

From 846851d30caaf3da56b5f97f7023f147c34515da Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Tue, 25 Aug 2015 19:56:00 +0200
Subject: [PATCH] vault: add vault container commands

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
---
 API.txt |  40 +++
 VERSION |   4 +-
 ipalib/plugins/vault.py | 180 ++--
 3 files changed, 216 insertions(+), 8 deletions(-)

diff --git a/API.txt b/API.txt
index afd5017bee2bc1eed54497ccd504b92619ff7a58..c45d332528b0cf5aa6b125b9c58cd3b3b8c970dc 100644
--- a/API.txt
+++ b/API.txt
@@ -5668,6 +5668,46 @@ option: Str('version?', exclude='webui')
 output: Entry('result', type 'dict', Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None))
 output: Output('summary', (type 'unicode', type 'NoneType'), None)
 output: PrimaryKey('value', None, None)
+command: vaultcontainer_add_owner
+args: 0,9,3
+option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui')
+option: Str('group*', alwaysask=True, cli_name='groups', csv=True)
+option: Flag('no_members', autofill=True, default=False, exclude='webui')
+option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui')
+option: Str('service?')
+option: Str('services', alwaysask=True, cli_name='services', csv=True, multivalue=True, required=False)
+option: Str('user*', alwaysask=True, cli_name='users', csv=True)
+option: Str('username?', cli_name='user')
+option: Str('version?', exclude='webui')
+output: Output('completed', type 'int', None)
+output: Output('failed', type 'dict', None)
+output: Entry('result', type 'dict', Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None))
+command: vaultcontainer_remove_owner
+args: 0,9,3
+option: 

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

[Petr Vobornik]

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?
--
Petr Vobornik
From d55fc09bc0cf2dd1054c8626b7bcdbba8cb219b9 Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Tue, 25 Aug 2015 19:56:00 +0200
Subject: [PATCH] vault: add vault container commands

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
---
 API.txt |  40 +++
 VERSION |   4 +-
 ipalib/plugins/vault.py | 184 ++--
 3 files changed, 220 insertions(+), 8 deletions(-)

diff --git a/API.txt b/API.txt
index afd5017bee2bc1eed54497ccd504b92619ff7a58..c45d332528b0cf5aa6b125b9c58cd3b3b8c970dc 100644
--- a/API.txt
+++ b/API.txt
@@ -5668,6 +5668,46 @@ option: Str('version?', exclude='webui')
 output: Entry('result', type 'dict', Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None))
 output: Output('summary', (type 'unicode', type 'NoneType'), None)
 output: PrimaryKey('value', None, None)
+command: vaultcontainer_add_owner
+args: 0,9,3
+option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui')
+option: Str('group*', alwaysask=True, cli_name='groups', csv=True)
+option: Flag('no_members', autofill=True, default=False, exclude='webui')
+option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui')
+option: Str('service?')
+option: Str('services', alwaysask=True, cli_name='services', csv=True, multivalue=True, required=False)
+option: Str('user*', alwaysask=True, cli_name='users', csv=True)
+option: Str('username?', cli_name='user')
+option: Str('version?', exclude='webui')
+output: Output('completed', type 'int', None)
+output: Output('failed', type 'dict', None)
+output: Entry('result', type 'dict', Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None))
+command: vaultcontainer_remove_owner
+args: 0,9,3
+option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui')
+option: Str('group*', alwaysask=True, cli_name='groups', csv=True)
+option: Flag('no_members', autofill=True, default=False, exclude='webui')
+option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui')
+option: Str('service?')
+option: Str('services', alwaysask=True, cli_name='services', csv=True, multivalue=True, required=False)
+option: Str('user*', alwaysask=True, cli_name='users', csv=True)
+option: Str('username?', cli_name='user')
+option: Str('version?', exclude='webui')
+output: Output('completed', type 'int', None)
+output: Output('failed', type 'dict', None)
+output: Entry('result', type 'dict', Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None))
+command: vaultcontainer_show
+args: 0,7,3
+option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui')
+option: Flag('no_members', autofill=True, default=False, exclude='webui')
+option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui')
+option: Flag('rights', autofill=True, default=False)
+option: Str('service?')
+option: Str('username?', cli_name='user')
+option: Str('version?', exclude='webui')
+output: Entry('result', type 'dict', Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None))
+output: Output('summary', (type 'unicode', type 'NoneType'), None)
+output: PrimaryKey('value', None, None)
 capability: messages 2.52
 capability: optional_uid_params 2.54
 capability: permissions2 2.69
diff --git a/VERSION b/VERSION
index d3073e52ee022cc08b74953222a5040929ded60f..58ab1a8e582e1c4213dd45217b052ef896f03166 100644
--- a/VERSION
+++ b/VERSION
@@ -90,5 +90,5 @@ IPA_DATA_VERSION=2010061412
 #  #
 
 IPA_API_VERSION_MAJOR=2
-IPA_API_VERSION_MINOR=154
-# Last change: pvoborni - change default vault type to 'symmetric'
+IPA_API_VERSION_MINOR=155
+# Last change: pvoborni - add vault container commands
diff --git a/ipalib/plugins/vault.py b/ipalib/plugins/vault.py
index