Linux Multi-user login

[illogic-al]

Fast user switching is available with KDE 3.2.

If the screensaver comes up (and locks the screen) you will have the option of logging in as another user (Start new seesion) or logging back in as yourself. Pretty nifty eh ;)

Edited June 24, 2004 by illogic-al

[illogic-al]

It works by default with the kde screensaver "launch new session".

Is true, and works pretty fine. exept for the sound that is disabled to the second user.

so that other users could log in with their own settings,

That is true in windows, but in linux the user do not has "own settings", insted they have a complete indempenden envairoment, with hig security. Others are not allowd to do what you not wanted them to do.

It is not "settings", it is an ACCOUNT.

Good by.

you can take care of the sound issue by modifying the permission

Open up the file /etc/security/console.perms and then scroll down to the sound section.

# permission definitions

<console>  0660 <serial>    0660 root.tty

<console>  0660 <floppy>    0660 root.floppy

<console>  0600 <sound>      0600 root.audio

you can either modify it so that only people in the sound group get to use sound.

# permission definitions

<console>  0660 <serial>    0660 root.tty

<console>  0660 <floppy>    0660 root.floppy

<console>  0660 <sound>      0660 root.audio

or do it so that everyone gets to use the sound

# permission definitions

<console>  0660 <serial>    0660 root.tty

<console>  0660 <floppy>    0660 root.floppy

<console>  0666 <sound>      0666 root.audio

If you do it by group, you will then need to add users to the audio group using drakuser

[theYinYeti]

I see...

The problem is to be able to make something happen (new login screen), even when xlock (or xlockmore, or...) is active. As those programs don't do it themselves, it would rely on a given keypress. And the solution should be DM- and WM-independant.

 

I once wrote a script that would be called by CtrlAltDel, for both graphic and text consoles. This script did offer the choice of going to a new login screen (login happened in text-console), as well as shutdown, reboot, locking the computer (this item never quite worked). The script was simply displaying a menu like that:

1: do this
2: do that
...
You choice?

 

This menu could surely be done graphically using a tool like Entity of Tk.

For what you want, The login could also be changed to graphic (for sure with GDM, maybe even DM-independant.

When I used the script, I relied on Fluxbox' key-catching for running the script. But this could easily be WM-independant by using xhkeys or xbindkeys.

 

The only thing I'm not sure of, is if the "catch-tool" receives the key-events, and hence can do things, when the locking is active...

 

What do you think?

 

Yves.

(for links to Entity and xhkeys, see http://www.gnu.org/directory/gui/other/)

[iphitus]

If i could work out the code to swap, from Ctrl-Alt-F7 (vc7) to Ctrl-Alt-F8 (vc8) i will write a program with Python and PyGTK when i learn that, which isnt too far away.

[Andrewski]

I see...

The problem is to be able to make something happen (new login screen), even when xlock (or xlockmore, or...) is active. As those programs don't do it themselves, it would rely on a given keypress. And the solution should be DM- and WM-independant.

Well, I think what you are suggesting is pretty much what I'm talking about; I guess I just had to explain myself more clearly.

 

To respond to what I quoted, couldn't it be set up to resume on top of (or instead of) xlock* so that one would not need to deliver a keypress? It seems like it could (or should be able to) resume after the screensaver turns off.

 

Man, I wish I had some programming skills to actually work on this... if I wanted to actually start learning this stuff, which language would I want to investigate? B)

[theYinYeti]

Hi !

 

I don't know what language would be best suited. Myself, I don't have time to setup a programming environment, and even less to use it. So I rely entirely on BASH, and the Unix & VT tools.

 

But as I told in my previous post, I'm not sure a keypress could be caught by anything when xlock* is active. So someone should try (me if I find time...), and in case of failure, there's still the hope that some xlock* program has the option to launch a command on wake-up...

Else, you're bound to go into the source, or at least contact the authors.

 

Yves.

[illogic-al]

I'd say going to the authors would be your best bet. Just go file a wish on gnome's bugzilla.