Home page logo
/

bugtraq logo Bugtraq 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
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



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]