[libvirt] [PATCH 8/8] nss: Lookup by libvirt domain names too

[Michal Privoznik]

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 <mprivozn at 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
nsswitch.conf:

  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.

Michal