LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Desktop (http://www.linuxquestions.org/questions/linux-desktop-74/)
-   -   Is it possible to do a dual user graphical login? (http://www.linuxquestions.org/questions/linux-desktop-74/is-it-possible-to-do-a-dual-user-graphical-login-4175467536/)

jnbbender 06-26-2013 11:17 PM

Is it possible to do a dual user graphical login?
 
I'm using RedHat on a system which requires that access is granted ONLY after two people have been authenticated on the machine. Figuring out which Effective UID they get after the login is another logistical issue I'll have to deal with later.
Can one mingetty process be run as a subprocess of another? I don't know!
Any ideas would be great.

dayid 06-27-2013 07:49 AM

Quote:

Originally Posted by jnbbender (Post 4979371)
I'm using RedHat on a system which requires that access is granted ONLY after two people have been authenticated on the machine. Figuring out which Effective UID they get after the login is another logistical issue I'll have to deal with later.
Can one mingetty process be run as a subprocess of another? I don't know!
Any ideas would be great.

You'll need to explain in further depth your setup (and ask a clearer question) to get any help.
  • In your post, what does "system" refer to? The hardware? A software/program/service?
  • When you say "after two people have authenticated"
    • Authenticated against what?
    • Authenticated since boot? (and possible logged out) or "...and are still logged in"
  • Presumably you're doing something with setuid if you're worried about the effective uid instead of just using the user's actual UID? Is this correct?
  • If so (above), how is it being used?
  • mingetty: try-it-and-see

jpollard 06-27-2013 08:50 AM

mingetty only works on unattached console terminals. Trying to run it on one that is busy just hangs.

I believe the reason it hangs is that it is attempting to establish a secure session to reset the terminal and start login.

jnbbender 06-27-2013 10:02 AM

Sorry, I'll try and be a little clearer. I haven't tried mingetty, it was just an uneducated guess at a solution. To start off I am not concerned with console logins.
My system is a RedHat 6.1 gnome GUI login screen on an pretty standard x86 desktop PC. I apologize I do not know which service runs the standard gnome GUI login screen presented to the user on run level 5.

Typically a person would login AT THE GUI, a gnome session would start and off you go. What I am wondering is - is it possible for one person to login at the gnome GUI (run level 5) AND THEN have the gnome login GUI present itself ONE MORE time so that another user must login before access granted.

Forget everything I said about UID, mingetty, etc.

dayid 06-27-2013 12:22 PM

What is the end goal you want to have?

Are you trying to create a system that uses "two man rule" to launch a particular service?

jnbbender 06-27-2013 12:33 PM

Yes

jpollard 06-27-2013 01:13 PM

Quote:

Originally Posted by jnbbender (Post 4979638)
Sorry, I'll try and be a little clearer. I haven't tried mingetty, it was just an uneducated guess at a solution. To start off I am not concerned with console logins.
My system is a RedHat 6.1 gnome GUI login screen on an pretty standard x86 desktop PC. I apologize I do not know which service runs the standard gnome GUI login screen presented to the user on run level 5.

Typically a person would login AT THE GUI, a gnome session would start and off you go. What I am wondering is - is it possible for one person to login at the gnome GUI (run level 5) AND THEN have the gnome login GUI present itself ONE MORE time so that another user must login before access granted.

Forget everything I said about UID, mingetty, etc.

Yes. It is possible.

What you have to do though is setup a "desktop" environment that does nothing but request another login. Once that second "login" occurs then the real desktop can be linked.

To do it though will require a specific login window - and it will not be running as root - so it will be "logged in" as the first user. The second login COULD change UID... but I'm not so sure that access to a GUI would work (the X authorization keys won't match or be available, and if available, then the second login could be spoofed).

This might be implementable by modifying a screen lock utility. The screen lock would then have to start the real GUI rather than just exit.

What you are doing is equivalent to a "captive login" from the command line. The way that works is that the first login has a specific shell to run - and all that shell does is verify a second (different) password before doing an exec of a real shell.

Note the limitation: the "user1" login must always be first, the "user2" password must always be second.

There are weaknesses involved here - 1. root can always bypass it. 2. any bug in the second login could leave user1 with normal access. This can be setup to "fail safe" but it requires a good bit of care in its setup.

BTW, in current RH systems the GUI service is in /etc/X11/prefdm.

In Fedora it changes drastically, and is much less well documented.

jefro 06-27-2013 02:45 PM

I'd wonder how secure this notion is. Any time someone has physical access to a system this two man rule fails.

You'd be more secure going with some dual password encryption scheme or maybe a complete remote system that required a dual password and time limits.

jpollard 06-27-2013 02:57 PM

Quote:

Originally Posted by jefro (Post 4979800)
I'd wonder how secure this notion is. Any time someone has physical access to a system this two man rule fails.

The only time the two man rule actually works is when the two keying stations are NOT the same. That is why all the missile launch systems required them to be turned on AT THE SAME TIME and the two stations were required to be more than two arms length apart.
Quote:

You'd be more secure going with some dual password encryption scheme or maybe a complete remote system that required a dual password and time limits.
That is all he was asking for. Is there a PAM module for that? It might be the easiest way to do it (wish I had thought of that for an earlier post).

jefro 06-28-2013 03:10 PM

Good point.

The only thing I have seen is dual usb encryption keys that needed to be attached. At one time they used parallel keys for this.

jefro 07-02-2013 02:30 PM

Wonder if any of the freeipa stuff would help?


All times are GMT -5. The time now is 10:23 AM.