Return to BSD News archive
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.mira.net.au!otis.apana.org.au!serval.net.wsu.edu!netnews.nwnet.net!reuter.cse.ogi.edu!uwm.edu!spool.mu.edu!howland.reston.ans.net!swrinde!cs.utexas.edu!uunet!psinntp!uprc.com!cygnus!z056716
From: lacoursj@fastlane.net (LaCoursiere J. D. (Jeff))
Newsgroups: comp.os.386bsd.development
Subject: chroot and pppd
Date: 3 Jan 1995 19:49:56 GMT
Organization: Union Pacific Resources Corp.
Lines: 64
Distribution: world
Message-ID: <3ec9p4$slp@clavin.uprc.com>
Reply-To: lacoursj@fastlane.net
NNTP-Posting-Host: cygnus.uprc.com
Keywords: chroot pppd
I am attempting to run stock pppd from FreeBSD1.1.5.1 in a chrooted area.
Like some other apps that I have been toying with, pppd attempts to open
/dev/tty to gain a file descriptor for the current terminal session. I
haven't traced the code completely, but I also saw some references to
ttyname(), which will fail in a chrooted area as well (if I remember
right, it gets the inode number associated with stdin and walks the /dev
tree looking for the correct device node... as the chroot happens after
login, the chrooted /dev tree will not contain a match, or perhaps the match
would be to a completely different device node.. egad!).
A couple questions:
1) Why does it have trouble opening /dev/tty ? My thinking is along the
same lines as ttyname()'s problems, but I don't have the internals
experience to validate them for the /dev/tty driver code...
2) Why does pppd (or any other app for that matter) need to open /dev/tty
at all? Could I not somehow use the stdin/stdout file descriptors
for changing the line discipline, etc. (me thinks I have missed
some basic understanding here :-> ).
I do have access to the device name associated with the current session, but
when I attempt to invoke pppd as follows (even outside the chrooted area),
I get permission type errors in syslog (sorry not being exact here, this is
from memory):
nebula# /usr/libexec/pppd crtscts -ip netmask 255.255.255.0 nebula:line1 /dev/ttyd2
(lock ttyd2 at 57600 baud in /etc/rc.serial, so didn't think I needed to give a
speed)
This is very difficult to debug from the chrooted area as syslog is not available
there (cannot use /dev/log, which is a socket in the real /dev). I did notice
that if the chrooted area is in the root filesystem, it works like a charm (as
long as I don't specify the device as above). In fact, a hard link to the real
/dev/log in this case enables syslog from the chrooted area. I was really hoping
that this kludge would tell me what is breaking in my non-root filesystem chrooted
area, but the damn thing worked (groan).
On a totally seperate note:
Would it be difficult to write a "proxy" syslog daemon that would run outside the
chrooted area listening to an open socket file called /chrooted_area/dev/log and
simply pipe requests to the real syslog? This would very useful.
Please be kind (donning asbestos clothing); my tty/socket programming knowledge is
somewhat slim...
TIA,
______/ Jeff LaCoursiere FastLane Communications
/ Network security/services mail info@fastlane.net
___/ lacoursj@fastlane.net
/
__/ ASTLANE Communications! Connecting America to the Internet...