This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Support NSS modules which can only provide a subset of authoritative answers.

The glibc NSS services delegate to the next available service.

The next service is considered authoritative. This supports
delegating answers if certain services are not yet initialized,
connected to their data sources, or empty.

The systemd nss_myhostname [1] service provides a useful way for
users to solve the problem of wanting a read-only /etc and also
having a consistent name for a locally configured system hostname.
Unfortunately the design has some fundamental flaws.

The nss_myhostname is a NSS plugin that is designed to go at
the end of the services list (overrides all services) but is not
actually authoritative over all service requests. This causes a
problem when you have myhostname at the end of the services
list and you happen to have an unreachable nameserver.

When the DNS server is unreachable, getaddrinfo is expected to 
return EAI_AGAIN.  However with nss_myhostname plugin at the end
of the services list it returns NODATA, resulting in getaddrinfo
returning EAI_NONAME, which is incorrect [2]. This is a fundamental
flaw in the design of nss_myhostname and the expectations of the
NSS services are not being met.

The nss_myhostname plugin wants to be authoritative for only a
subset of the possible service requests, and that is not allowed.

Given that nss_myhostname solves a real problem by providing
dynamic configuration to the system configuration I considered
how we might possibly allow servies that are authoritative only
for a subset of all possible requests.

One way is to save the previous service answer, and allow the
service to indicate the current request is outside of it's
own authoritative scope e.g. mark itself as "skipped", causing NSS
to use the answer provided by the last service.

You need to have one service which never returns "skipped" or you'd
have no results returned, but that's a relatively easy to detect
system configuration error e.g. all services "skipped" but the
previous service answer is not initialized.

I don't know what that API would look like, but my hope is that
we have some discussion about the high-level details before going
down to the API level.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]