Re: chroot'ed environment?

[mouse () Collatz McRCIM McGill EDU (der Mouse)]

> > Also, if it is not too off-topic, what would be the best way to
> > allow syslogs after a chroot, if the syslog daemon uses unix
> > datagram sockets, that dont survive the chroot call?

> There are several approaches that have been used; all have their
> limitations.  You could change the syslog subroutine to use the UDP
> port.  You could use a UNIX stream socket.  Or there's a hack that
> works on some systems, if you need only one chroot'ed syslogd...

> Make /dev/syslog a symlink to the real location of the socket,
> perhaps /usr/ftp/dev/syslog.  Fire up syslogd with the (often
> undocumented) -p option, telling it the real location.

If I might offer the solution I use for my ftpd....

Hardlink /dev/log to /ftp/dev/log.  You need to do this each time
/dev/log is recreated, of course.  It depends, of course, on the ftp
chroot() area being on the same filesystem as /dev/log.

If all your chroot areas are on the same filesystem, but different from
/dev, you may be able to combine these two ideas: make all the chroot
/dev/logs hardlinks to one another, and symlink the non-chroot /dev/log
to some one of them.

An idea which just occurred to me, not tested at all.  If you can
connect() an AF_UNIX SOCK_DGRAM socket (and I'm not sure you can), the
association with its peer might survive a chroot that renders the
original pathname inaccessible.  If this is so, it could provide an
answer.

And, of course, you could always write a stupid little daemon that does
recv()s on /ftp/dev/log and turns around and sendto()s the packets to
the real /dev/log.

                                        der Mouse

                            mouse () collatz mcrcim mcgill edu