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

[S.Sakamoto]

Hi, Daniel

> >    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>
> >        <domain> was destory ...        -- I think that this behavior is a problem
> 
> Yes, that is a problem.

I intended to have made it to solve this problem, But...

> 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. 

If include user authentication, it solve the problem. I think so too.
Therefore I retire from this problem.



Thanks,
Shigeki Sakamoto.






> > 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>
> >        <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  -=| 
>