On Tue, May 29, 2007 at 04:44:15PM +0900, S.Sakamoto wrote:
> Hi, Dan
>
> Thanks for your comment.
>
> > It will prove unreliable in practice, because even if you
> > fix a particular guest on port 5905, any other guest doing dynamic VNC port
> > assignment may choose this port before the hardcoded guest starts.
> This situation is surely thought.
> But, I think that problem is solved
> if it performs a repetition check of a port number in virt-inst.
> When it is this situation, at first,
> examine the port number that all other guests use when it starts a guest.
> Next, If the port number is fixed and repetition,
> output a message. [e.g."Repetition. Set a different port number."]
> (However, there is not a function setting a port for an existing guest now.
> If it is necessary at the same time,
> I make 'check of repetition' and 'function setting a port for an existing guest'.)
>
> > It is not going to be easy for virt-manager to do validation of this port number
> > either, since in the near future virt-manager may well be running remotely
> > from the host.
> If it adds a revision to libvirt side to get a port number from the information that acquired from xend,
> the acquisition of a port number will be easy.
>
> > this is a very small niche usecase
> I do not think so. and I think that there is a person to need surely.
> Because, I think that it can perform the prevention / maintenance
> by the pair of guest and port-number are managed.
> For example, The person who thinks about maintenance for the port which opened out
> had better be a fixed port number.
> If it does't know whether it has already opened or it will open out from now on,
> it will become difficult to deal with possibility of attack to an opening port.
> Therefore,
> the user who wants to open only a specific port for a firewall needs to fixed port number.
> And, even if it can get a dynamic port from remote connection in the future,
> he needs a fixed port number at the time of remote connection too,
> because he wants to connection with only a specific port.
There's two possibilities to consider:
a. The admin of the Dom0 permanently opens up a range of ports (eg 5900->5920) to allow
upto 20 vms to have their console accessed at any time. In this case, whether you
use fixed or dynamic ports per VM, you still need 20 ports open, to run 20 consoles.
b. The admin of the Dom0 only opens specific ports for short periods of time. In this
case the admin will have to lookup what port corresponds to a VM, so it doesn't matter
whether we're using fixed or dynamic ports, the admin still has same amount of work
to lookup a port.
So, I still don't see that using fixed ports in virt-manager has any benefit for the
administration POV.
Neither of these two options are entirely satisfactory though - it would be desirable
to only open up a port when explicitly needed, and not require the admin to do any
work. One might even suggest that libvirt should have some form of API to let the
remote user request access to the cosnole - authenticated of course
virDomainAllowConsole(virDomainPtr, const char *ipaddr);
virDomainDisallowConsole(virDomainPtr, const char *ipaddr);
Calling either of these functions would add neccessary iptables rule to allow
access to the console for that particular domain, from the specified ip address.
When the virConnectPtr object was closed, then any rules would also automatically
be removed.
This would allow virt-manager to securely request access to the console without
needing permanent iptables rules.
These's probably quite a bit more to think about wrt to iptables, consoles
and seecure authentication. In the very near future libvirt will have the
support for remote management merged and we'll be in a position to experiment
with these ideas for real. So I don't think we want to add support for fixed
port numbers in the virt-manager wizard until we've tried out some of these
ideas.
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 -=|
