On 30.11.2016 11:41, Michal Privoznik wrote:
> On 30.11.2016 11:16, Daniel P. Berrange wrote:
>> On Wed, Nov 30, 2016 at 10:59:35AM +0100, Michal Privoznik wrote:
>>> So far the NSS module looks up only hostnames as provided by
>>> guests themselves. However, there are some cases where this is
>>> not enough: e.g. when there's a fresh new guest being installed
>>> (with some generic hostname) say from a live ISO image; or some
>>> (older) systems don't advertise their hostname in DHCP
>>> transactions at all.
>>> In cases like that it would be helpful if we translate domain
>>> name as seen by libvirt too so that users can:
>>> # virsh start $dom && ssh $dom
>>> Signed-off-by: Michal Privoznik <mpriv...@redhat.com>
>> So, IIUC, with this change the nss module is able to lookup
>> based on hostname *or* the guest name.
> Correct. If you have a libvirt domain 'fedora' but set its hostname to
> 'fedora2', both 'ping fedora' and 'ping fedora2' will work (and result
> in the same IP address). Without this patch just 'ping fedora2' would work.
>> I think it is desirable if the admin can control which is
>> used. In particular as an admin I'd like to prevent the
>> ability to use hostname at all, since this data may
>> come from an untrustworthy guest.
> Which can happen on a real network too. Guests can initialize DHCP
> transaction with spoofed hostname just to trick DNS. If admins don't
> want this to happen they just configure static DHCP/DNS. With libvirt,
> they don't enable the NSS module.
>> IOW, should we actually create two separate NSS modules,
>> one that does DHCP hostname based lookups and one that
>> does guest name based lookups. Admins can then choose
>> which to use, or even list both in nssswitch.conf
> I was thinking about this and honestly, I don't have preference. I could
> argue both ways. Ideally, there would be a way to pass arguments to an
> NSS module, but looks like there is none. I've seen the following in
> netmasks: nisplus [NOTFOUND=return] files
> which would suggest so, but digging deep into glibc those are just args
> to glibc function that loads the modules and calls the functions from them.
> So yes, maybe we need two modules after all. Any suggestions on the
> naming? I'm out of ideas.
Just an idea: what if I rename the current module to libvirt_guest (and
also install symlink named libvirt that would point to it - just to
maintain backward compatibility). And this new module would be called
libvirt_host. So that we would have:
libvirt_guest: to resolve IP addresses based on what guests say
libvirt_host: to resolve IP addresses based on what libvirt thinks the
guest name is.
Still crappy names though.
libvir-list mailing list