mDNS support

u-uclibc-qs50 at u-uclibc-qs50 at
Wed Feb 1 20:25:21 UTC 2012

On Wed, Feb 01, 2012 at 12:09:20PM -0500, Rich Felker wrote:
> On Wed, Feb 01, 2012 at 10:59:15AM +0100, u-uclibc-qs50 at wrote:
> > Hardwiring is generally harmful. Could we make this run-time configurable
> > somehow, like using an environment variable? Otherwise I'd be forced to
> > add such functionality anyway to my builds... It would be certainly useful
> > in general, lifting the otherwise arbitrary limitation on the host setup.
> One way you can make it configurable by hard-wiring
> "/etc/avahi-socket" and letting the admin make that a symlink to the

I agree, symlinking would help when avahi has one compiled-in path
and the library (or different instances of libraries) have different
compiled-in ones. Then a proper set of symlinks may let them work together.

This would work around some problems - but unfortunately does not fit
in a general case anyway. See below.

> actual socket (assuming symlinks to sockets they? If not you
> could readlink it first.) Using environment variables is unacceptable
> (from an admin standpoint at least) because it can't work with setuid

Sure, the whole concept of setuid relies on the user not being
able to influence the behaviour of such binaries.

Accidentally I do not depend on setuid much, but instead depend heavily on
one being capable to run software on every host, even oddly setup, without
ever becoming the superuser or relying on the superuser cooperation
(which would be necessary for setting up symlinks or similar).

So a possibility to tune an application for a host, _not_ vice versa
is crucial.

In my eyes a working compromise would be to have compile time alternatives:

- the traditional one, a hardwired socket path

  (simple and deterministic, not usable without superuser cooperation)

- using an environment variable with an optional:
  - check for being setuid then ignoring mDNS and/or an optional:
    - fallback to a hardwired socket path

  (safe still quite general, at a small cost in the checking code, if any)

I would be happy to contribute the additional (optional! :) code
as soon as 1. the first alternative is available/committed and 2. there
is a chance for the functionality to be accepted.

Of course the idea of using a library and running programs without any
provisions from the local root may seem strange for many of you seasoned
system administrators. If you think about it though, it is not only
possible but even extremely useful (among other things making the life
of the local host administrator a _lot_ simpler).

[For the record, I am writing this very letter as usual with an x11
terminal emulator, a text editor, a MUA, going to submit it to a mail
server, all of them running software which is basically independent
of the local host(s) setup (and not "installed" either, being run from a
global file system).]


More information about the uClibc mailing list