Date: Sat, 23 May 1998 23:53:13 +0100 From: Brian Somers <brian@Awfulhak.org> To: Bruce Evans <bde@zeta.org.au> Cc: brian@Awfulhak.org, archie@whistle.com, freebsd-current@FreeBSD.ORG, julian@whistle.com Subject: Re: **HEADS UP** user-ppp has changed ! Message-ID: <199805232253.XAA26943@awfulhak.org> In-Reply-To: Your message of "Sun, 24 May 1998 03:54:09 %2B1000." <199805231754.DAA02639@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> >> Access to a controlling terminal is revoked when its controlling process
> >> goes away. See kern_exit.c.
> >
> >Is there any way of avoiding this ? Perhaps relinquishing terminal
> >control up front, *then* passing the descriptor ?
>
> Releasing a controlling terminal earlier just gives a dead descriptor
> earlier. Session leaders can switch the controlling tty (hopefully
> only when switching is secure).
>
> >The only other alternative is to keep a `/bin/cat' running - in which
> >case I may as well do the `two /bin/cat' approach.... that way they
> >get a SIGPIPE when something goes wrong and everything dies nicely.
>
> Why would cat be the controlling process? I'm not sure what the
> controlling process is here. If it's a login shell, then don't kill
> it.
This is for dial-in access. The same remote ppp dials in to the
local box twice. Ppp identifies that the guy on the other side is
the same and ``joins'' the links into one ppp daemon.
They both begin as the controlling tty of their respective links.
Both try to create a local socket, and the race looser connect()s
to it and passes the STDIN descriptor to the other using sendmsg()
& SCM_RIGHTS.
The other side can use the descriptor all the way up until the
connect()ing process realises it's got nothing else to do and exits.
As soon as the exit() happens, the device ttyclose() happens
(in kern/tty.c) and the guy with the descriptor gets a descriptor
exception from select() and falls on its face.
The `cat' idea is to simply have the connect()ing side send some
regular data about the link, and then fork() & exec() two instances
of /bin/cat, attaching the socket descriptor and the tty to either
end. The accept()ing side uses the socket descriptor as its modem
device. I didn't like this idea 'cos I'm using up two processes
too many :-(
What'd be really nice is if there was some way of donating PGRP
rights to the other side of a local socket - I'm not allowed to
tcsetpgrp() 'cos the other ppp isn't part of my session. This
would be similar to SCM_RIGHTS & SCM_CREDS, but would affect the
tty in that the tty would zero its session pointer and change it's
PGRP pointer to that of the receiver. It's probably trickier than
that though :-/
Any comments ?
> Bruce
Thanks.
--
Brian <brian@Awfulhak.org>, <brian@FreeBSD.org>, <brian@OpenBSD.org>
<http://www.Awfulhak.org>;
Don't _EVER_ lose your sense of humour....
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805232253.XAA26943>