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