Re: [Freeipa-devel] [PATCH] 916 vault: add vault container commands
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 va
Re: [Freeipa-devel] [PATCH] 916 vault: add vault container commands
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 abou
Re: [Freeipa-devel] [PATCH] 916 vault: add vault container commands
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
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 f
Re: [Freeipa-devel] [PATCH] 916 vault: add vault container commands
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 fails(he
Re: [Freeipa-devel] [PATCH] 916 vault: add vault container commands
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 "" -- 2. Invalid description of vaultcontainer-show "Display information about a vault." 3. Something which needs to be fixed: Setting password for first vault without a vault container fails(here run as vault admin but the same issue is present when it'
Re: [Freeipa-devel] [PATCH] 916 vault: add vault container commands
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 ] https://fedorahosted.org/freeipa/ticket/5250 --- API.txt
Re: [Freeipa-devel] [PATCH] 916 vault: add vault container commands
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
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
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
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
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
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. -- Petr Vobornik From 7ef2a5580f06103d803e2ec2e85315a40d5e8666 Mon Sep 17 00:00:00 2001 From: Petr Vobornik 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 Date: Tue, 25 Aug 2015 19:56:00 +0200 Subject: [PATCH] vault: add vault container commands 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 --- 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', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) output: Output('summary', (, ), 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', , None) +output: Output('failed', , None) +output: Entry('result', , 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, cl