bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: console-client close to initial check in


From: David Walter
Subject: Re: console-client close to initial check in
Date: Wed, 11 Sep 2002 14:19:38 -0400
User-agent: Gnus/5.090007 (Oort Gnus v0.07) XEmacs/21.4 (Honest Recruiter, hurd-i386-debian)

Marcus Brinkmann <address@hidden> writes:

> On Wed, Sep 11, 2002 at 01:48:25AM -0400, Roland McGrath wrote:
>> It doesn't seem especially elegant,
>> but it ought to be adequate to ahve a simple feature where the console
>> server just runs a specified shell command to do something interesting the
>> first time you switch to a virtual console.
>
> Mmmh, yeah, that could work.  Maybe when it also handles the ttys directly.
>
>> > BTW, is there a way to get a getty on it even after boot?  
>> 
>> What do you mean?  kill -1 1 should make runttys reread ttys.  (Really just
>> SIGHUP to runttys, but signals are supposed to propagate from init to
>> runsystem to runttys so you can just use PID 1 as is the BSD convention.

Won't this have to be addressed in some system/user configurable way anyway?

I was   thinking  about this as  I   have  been  using console-ncurses
daily. When  I multi-attach remotely, or  locally, I receive _exactly_
the  same vconsoles regardless  of login (userid).   I  view this as a
very desirable feature. However, This would  pose a security hole, but
this gives some other interesting options I think.

One of the options might be to have a mapping descriptor? (read that a
translator) on some node /dev/vc?

This node verifies the attaching uid and maps to  a session within the
console server. 

Then user x gets X session.
     user y gets Y session.

For example now /dev/vc/{1,2,3,4}/{console,input,display}
future          /dev/vc/{uid1,uid2}/{1,2,3,4}/{console,input,display}


Or more explicitly:
 Current: (more or less)
 /dev/vc/1/console
 /dev/vc/1/input
 /dev/vc/1/display
 /dev/vc/2/console
 /dev/vc/2/input
 /dev/vc/2/display
 /dev/vc/3/console
 /dev/vc/3/input
 /dev/vc/3/display
 /dev/vc/4/console
 /dev/vc/4/input
 /dev/vc/4/display

 New:

 /dev/vc/0/1/console
 /dev/vc/0/1/input
 /dev/vc/0/1/display
 /dev/vc/0/2/console
 /dev/vc/0/2/input
 /dev/vc/0/2/display
 /dev/vc/0/3/console
 /dev/vc/0/3/input
 /dev/vc/0/3/display
 /dev/vc/0/4/console
 /dev/vc/0/4/input
 /dev/vc/0/4/display

 /dev/vc/1000/1/console
 /dev/vc/1000/1/input
 /dev/vc/1000/1/display
 /dev/vc/1000/2/console
 /dev/vc/1000/2/input
 /dev/vc/1000/2/display
 /dev/vc/1000/3/console
 /dev/vc/1000/3/input
 /dev/vc/1000/3/display

I suppose that /dev/vc is a console-uid-mapper and each /dev/vc/uid is
a console-client.

Seems   like  this will require  a  dynamic  getty restart as  well as
allowing getty's  to die on logout+timeout so  that the system doesn't
become full of dead consoles, plus  activate on switch to console. Not
just the first time used, but whenever there is no getty.

Or more slowly:

A user UID 1000 logs in on the system console.

He starts up the console-client on /dev/vc.

He logs in on vc/{1,2,3}. Does something. logs out of vc/{1,2}

UID 1000 walks away with an emacsen on vc/3.

Meanwhile, vc/{1,2} have been de-activated  with a login timeout which
is followed by a getty death and detach.

Then  uid   1000 logs   in   remotely using   ssh,   and  reconnects a
console-client to /dev/vc,  either the old console  3 is now active as
console 1 or switch to console 3 and viola emacs  session where it was
left.

-- 
/^\
\ /     ASCII RIBBON CAMPAIGN
 X        AGAINST HTML MAIL
/ \




reply via email to

[Prev in Thread] Current Thread [Next in Thread]