|
|
|
|
|
|
|
|
|
|
xen-users
Re: [Xen-users] communication between dom0 and domu
On Thursday 01 September 2005 22:11, Arijit Ganguly wrote:
> All,
> Is there any way we can set up a communication channel (not a TCP/IP
> based network) between domain0 and unprivileged domains. This can be
> useful in a way that we can write automatic configuration mechanisms
> for our unprivileged VMs.
From what I heard, XenFS will allow that kind of communication, for it will be
possibe to mmap a file from it in different domains and have shared memory
between domains that way.
But thats still far from "running commands" in a target domain, so you'll
still need some application to do that for you...
Easiest solution for your problem would be probably a shared directory with
dom0 putting shellscripts or executables into, and domU polling that
directory, executing and deleting whatever it finds...
But it'll be some time till XenFS will be available...
> Illustration:
> I have a domainU running on a host, which doesn;t have network
> connectivity (like ssh). I just use the VM as a environment I can
> issue commands and get results. Ports on domain0 are blocked
> preventing me from accessing the VM console. I do not have an account
> in domain0 for security.
> What can be done is running a truested software on domain0, which
> takes commands and runs them inside domainU and returns me the
> results.
>
> The bottomline is a communication channel between dom0 and domU. Any ideas?
Well, if its just that you want to "jail" suspicious software started from
dom0 in a domU:
- mount the domU FS in dom0.
- put your app in it, say /bin/something
- unmount domU root
- patch "init=/bin/something" into your domU config file as kernel param
- xm start domU
- wait till timeout or shutdown of domU, xm stop it
- mount domU Root FS
- read results...
- maybe use a modified startscript or an entry in inittab instead of the
"init=..." kernel param.
If you just want to exchange some configuration data on domU, put it onto
domU's kernel commandline, and read it back from /proc/cmdline inside domU
But I'd still say that a private bridge between domU and dom0 (not connected
to any real network device) and running ssh on it would be a more sensible
method. Without routing and maybe some ebtables scripts on it, that bridge
would be quite secure.
Did you have a look at the vserver kernel patches and tools
(http://linux-vserver.org/)? Those might be by far better suited for your
problem.
HTH
/Ernst
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
|
|
|
|