vapier at gentoo.org
Wed Feb 1 18:50:57 UTC 2012
On Wednesday 01 February 2012 12:09:20 Rich Felker wrote:
> On Wed, Feb 01, 2012 at 10:59:15AM +0100, u-uclibc-qs50 at aetey.se wrote:
> > 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).
this sounds good to me. symlinks to sockets seem to work fine with a quick
cd /dev && mv log x && ln -s x log
strace logger asdf
rm -f log && mv x log
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: This is a digitally signed message part.
More information about the uClibc