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