[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libvir] [PATCH] About remote operation restrictions of a general user



On Thu, Apr 12, 2007 at 02:14:37PM +0900, S.Sakamoto wrote:
> Hi, Daniel
> 
> Sorry, I think that explanation was not enough...
> 
> 
> About "virsh connect" of Xen:
> 
> When a general user has access to remote,
> he can't carry out a command of "virsh --connect xen start <domain>",
> but, he can carry out a command of "virsh --connect http://10.xx.xx.xx:8000 start <domain>".
> (What is a kind of Hypervisor? not judge it to be it.Therefore this is not ReadOnly.
>  "virsh.c - vshInit" decides "R/O" or "R/W" by the result that judged a kind of Hypervisor to be it.)
> 
> I think that it is a problem that a general user can carry out command (e.g."start","destroy").
> 
> 
> So, I make the patch which prevented remote control using the following problem.
> 
> 
>    1)in general user
>      # virsh destroy <domain>
>        operation virDomainCreate forbidden for read only access        -- I agree with this behavior
>      # virsh --conexct xen destory <domain>
>        operation virDomainCreate forbidden for read only access        -- I agree with this behavior
>      # virsh --conect http://10.xx.xx.xx:8000 destroy <domain>
> ?$B!!!! ?$B!!<domain> was destory ...        -- I think that this behavior is a problem

Yes, that is a problem - a problem with XenD though - it insanely allows
complete control over any domain when connecting over TCP+HTTP. Everyone
strongly recommends against turning on the TCP+HTTP server in XenD for
this reason. In Fedora we only turn on UNIX+HTTP server, so only root is
able to connect to XenD.

In the new XenAPI, the TCP+XMLRPC service will include user authentication
so it will be possible to explicitly allow full operational access to XenD
by a non-root user. 

> 
>    2)in root user
>      # virsh destroy <domain>
>        <domain> was destory ...        -- I agree with this behavior
>      # virsh --conexct xen destory <domain>
>        <domain> was destory ...        -- I agree with this behavior
>      # virsh --conect http://10.xx.xx.xx:8000 destroy <domain>
>        <domain> was destory ...        -- I agree with this behavior

Basically libvirt/virsh should not be enforcing policy in this scenario. virsh
should always default to a read-write connection, except in the case of using
Xen locally as a non-root user, where we know that read-only is required due
to the libvirt_proxy only allows read-only.

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]