> On 26 Feb 1999, in message <000f01be60ec$4f61a420$d06026c2@csaba>
> "Sebestyén_Csaba" <sebcsaba@freemail.c3.hu> wrote:
> | I'm missing a function from the Linux. (I speak about a single computer,
> | without network, and about the text mode, certainly.) One time more users
> | can log in, but they can reach the other's tasks. And if i logged in, and i
> | want a new shell i have to type my username and password again. I'd like to
> | switch between my tasks, but if another people sit down to this computer
> | (and i just suspended my tasks, and didn't logged out), they wouldn't reach
> | my tasks.
> |
> | For example: i can change users by Ctrl+Fn keys, and tasks (as now) by Alt+Fn.
> | First user is joe, and the second is jack.
> | Now jack is working, on his first consol.
> | He press Alt+F2, and he gets a new shell, but he doesn't have to type his password.
> | But when he press Ctrl+F1, he can't work until he types joe's password.
> | And if he press Ctrl+Esc, he gets a list about the users currently logged in
> | (and on what consol). Whe he press Alt+Esc, he gets a list about all tasks
> | currently running (and on what consol).
> |
> | It would be a good function, if more people use one computer by turns (for
> | example a family).
>
> If I understand you, you wish to have multiple sessions active (one per
> family member for the example), all accessable from the console. And
> that one member not be able to access another member's session without
> a password.
>
> I infer that this is because you wish to not lose the state you've
> built up in the course of using the session (command history, etc etc).
> And also the multiple tasks you may have open - editors, whatever.
>
> I think the nearest solution to your probelm at present is the "screen" program.
> This
> - lets you have multiple sessions on the one console
> - lets you detach without killing the sessions
>
> You should be able to find an rpm for "screen" at:
>
> http://rufus.w3.org/linux/RPM/
>
> Between them, this may do what you want. You arrange that everyone runs
> screen (by hacking /etc/profile, most likely). When a person leaves the
> console they detach their screen session and log out like normal. When
> next the sit down they log in as normal and reattach to their detached
> screen session.
>
> This may do it for you.
Too bad screen supports only black'n'white pure vt100 properly (yes
there've been poor quality hacks for basic ansi color support...)
I'm considering writing a getty replacement for this kind of thing...
but a pure user-level solution looks to be near impossible (that is,
insane waste of cpu & memory & too complex to implement...) as Linux has
several "unsafe" escape sequences and ioctls (chvt, ...)
That means I need to process every escape sequence instead of just the
ones used to control this getty replacement thingie unless I tell the
kernel to disable those unsafe things when the getty replacement is in use
Also the current model of running a getty for every tty is really stupid...
The VT logins should be handled by one process which'd allow spawning a
new login shell with a single loadkeys-definable "key" for the current
user, handle user session locking and so on... also the alt-fX (or
whatever you want to use to change the consoles) could easily be redefined
by the program to go to current user's VT #x instead; that could be named
virtually numbered virtual consoles or something like that ;)
(from the secure-the-console viewpoint the current user shouldn't need to
know anything about the other users besides the fact they exist)
Also we'd need some easy way to reset the keyboard mode from RAW to
something the normal programs understand... and NOBODY besides ROOT should
be allowed to lock the console so that others can't access it at all...
Everybody should have a simple way to lock their own session though.
Anyone ever thought about implementing this kind of things?
Any other comments, flames, plain FUD or something? ;)
[as a partially related note I'm also considering an user-level console
implementation... and maybe some fb trickery too... if I ever have time to
get started that is ;)]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/