mailing list archives
Re: chroot'ed environment?
From: mouse () Collatz McRCIM McGill EDU (der Mouse)
Date: Wed, 19 Apr 1995 17:47:13 -0400
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
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.
mouse () collatz mcrcim mcgill edu