Re: [gdm-list] limiting access
- From: Brian Cameron <Brian Cameron Sun COM>
- To: Yan Seiner <yan seiner com>
- Cc: gdm-list gnome org
- Subject: Re: [gdm-list] limiting access
- Date: Tue, 09 Sep 2008 18:05:02 -0500
Yan:
You could set up some cron jobs. You could run gdm-stop to terminate
all user sessions and run gdm-start to allow users to start logging in
again. There are probably a variety of mechanism you could use via cron
to give the users some advance warning of the shutdown.
OK, I can do that. Now I have to figure out an xorg equivalent of 'wall'....
I know it's out there, I just can't lay my hands on it....
You could probably write a script that pops up some zenity dialog. If
you ran a script as root, you could access all the DISPLAY Xauth keys
from /var/lib/gdm so you could display the dialog on each display.
There are probably lots of ways you could do this, though. It probably
wouldn't be that hard to write your own infrastructure to do what you
want.
The drawback with this approach is that GDM simply won't manage the
displays while turned off, so you would need to figure out some
mechanism to display the "user logins are not permitted" message on
each display.
Right. I really want gdm to do that; it would make life simpler if the
machine is rebooted during the 'no login' period to have gdm check the time
and select the appropriate login screen. Is there somewhere in the /etc/gdm
hierarchy where I can hook into one of scripts and hack up a time check, and
then select a login theme?
You could hack the PreSession script to check the time, pop-up a dialog
saying "Sorry" and then when the user clicks OK, just return a non-zero
failure code from the PreSession script and it should go back to the
login screen without letting users log in. If you modify the
PreSession script it should take effect imeediately for all future
logins.
There's no easy way to kill running sessions, though you could probably
do it via the "kill" command, by killing the slave gdm-binary process
associated with each display. If you did this after the PreSession
script disallows people from logigng in, this might work. Or you could
just stop and restart the main GDM daemon by running gdm-restart.
During the "down" period you could restart GDM with a PAM stack
which denies all login attempts and displays the "user logins are
not permitted" message if you really wanted this message to come from
GDM. As I say, there are probably other methods you could use to
display such a message, though.
I'm not that familiar with PAM + gdm - it all 'just works' and I have not
needed to dig in to PAM a whole lot.
How do I start gdm with a custom PAM stack? I only need to deny logins on the
X sessions, not on the command line.
Lots of questions, and I appreciate any help I can get. This is for a school,
and I am denying logins during morning roll call and class startup.
Unfortunately PAM is configured in different ways on different OS's.
You really need to research how PAM is configured to deny login attempts
for your platform.
However, if you take the above PreSession script approach you could
avoid messing with this. The advantage of modifying your PAM
configuration is that you have more control over the prompts that are
displayed in the GDM login GUI and you can avoid the authentication
step ever happening. For example, you could probably write your own
simple PAM module which just denies authentication and provides a prompt
that says "Sorry no logins now" or something.
Brian
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]