Re: [uml-user] Problems reconnecting to serial line

[Paul W. <pd...@ex...>]

On Tue, Mar 02, 2004 at 10:22:10AM -0700, Dan Lund wrote:
> 
> >You can detach (Ctrl-A D) but you can't quit (Ctrl-A \ or Ctrl-A Q or
> >whatever it is), as this causes the TTY to hang up, and if you used that
> >TTY for output from init during boot, it won't respawn.
> >
> >Do you see different behaviour when you quit screen?
> >
> When I quit screen, I don't really "quit". I just detach from it. I 
> usually either do a ctrl-a d as you said, or I just close the xterm 
> because I'm almost always in XWindow. Screen does have the ability to 
> alter keys, so you can turn that feature off. I use screen as an 
> ameteur, so basically it's features are completely unused by me other 
> than detaching and naming. I do know that the ctrl features are 
> alterable with screen, though.

Yeah, but I'd rather not use screen at all for security reasons.  I'd
rather work on a patch to UML for what I see as a bug, than work on a
patch to screen to remove features.

> >>I use screen for all of my UML sessions, and it's really idiotproof.  
> >>That's an important feature for me, considering I'm using it.
> >>But, if you don't want screen available to the users, you can run screen 
> >>as another uid, and make the serials available.
> >
> >I don't understand what you're suggesting here.
> >
> Having a primary console via screen is all well and good, but having a 
> serial console is probably the better way to go for less vulnerability 
> when it comes to what a user does. (such as quitting screen, as you said 
> above) That's what I'm suggesting. 

I don't understand the distinction you make between a serial console and
a primary console.  I want the users to be able to access the console at
boot time.  I guess this makes it a primary console.  However I'm
currently doing this by setting up the UML with a console on a serial
port, attached to a pts in the host.

> Perhaps having a a serial console 
> available for the user, instead of giving them direct access to the 
> primary "screen" session.

Unforunately the whole aim is to give them access to the primary (boot
time) console.   Otherwise, I wouldn't have a problem.

I've have already spent a few hours working on a patch, but I'm totally
unfamiliar with either the UML or kernel codebases, so doing so is like
wading through treacle and I've made very little progress. 

I'd be very grateful for any pointers on how this stuff works, and what
I should be looking to do to prevent a tty hangup and to respawn the pts
after it is closed. 

cheers,

Paul