As I commented in Aline's authorization patch, I think we get to the
point to split Linux user/group with kimchi user/group,
1. we want different admin just responsible for their own parts:
network admin manage network, storage admin manage storage, but
superuser/un-previledged user does not have such fine grained view.
2. we want multi-level of access of one tab:
take guest management as an example, we want
create/destroy--start/stop--access vnc, at least 3 levels of access.
superuser way cannot reflect multi-level control.
On 2014年07月12日 03:08, Crístian Viana wrote:
This is a working version of the patchset. It will use the users and
groups
metadata on each VM to decide if the current user is able to perform an
operation on the VM. If the user (1) has sudo access or (2) is listed in the VM
'users' metadata or (3) is part of at least one of the groups listed in the VM
'groups' metadata, they will be able to see and perform any operation on that
VM.
The VMs listed by /vms are also filtered by the current user's permissions.
This patch contains the actual feature implementation. The tests and appropriate
updates to the mockmodel are not ready yet, as they happen to require more
changes in the current code than expected.
Crístian Viana (1):
Filter VMs by users and groups
src/kimchi/control/base.py | 4 +++
src/kimchi/model/vms.py | 63 ++++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 65 insertions(+), 2 deletions(-)