mDNS support

[Rich Felker]

On Wed, Feb 01, 2012 at 10:59:15AM +0100, u-uclibc-qs50 at aetey.se wrote:
> Hello,
> 
> Looking at Subj and the the thread
>  http://lists.uclibc.org/pipermail/uclibc/2011-November/046020.html
> 
> (Was the change commited somehow?)
> 
> The approach of socket communication is good, compared to the one of
> plugins-as-shared-libraries taken by glibc. (Address space isolation
> between the independently maintained codebases is extremely important.)
> 
> One thing which bothers me is
> 
> +config UCLIBC_AVAHI_SOCKET_PATH
> +	string "Path to avahi unix domain socket"
> +	default "/var/run/avahi-daemon/socket"
> +	depends on UCLIBC_HAS_AVAHI_RES
> +	help
> +	  A running avahi-daemon creates a socket to listen for queries.
> +	  Enter the path you configured your avahi-daemon to.
> 
> It is sometimes crucial to be able to use the same binary in different
> circumstances - e.g. on differently setup hosts, using different sockets
> paths.
> 
> Unfortunately Avahi hardwires its socket path, but let us do better.
> 
> 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
actual socket (assuming symlinks to sockets work...do 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
binaries (either you must ignore the env var and break support, or
honor the env var and make all setuid binaries vulnerable).

Rich