GNOME.org
 

Re: [gdm-list] Request for info: number of logged users


Rui:

Sorry this took some time to respond...


From: Brian Cameron <Brian Cameron Sun COM>

I think a better solution to this problem would be to pop-up a dialog
asking the user if they really want to shutdown/reboot the machine.
This is what is done on Windows if you are logged in as multiple users
and select Shutdown, for example.

It might be a bit confusing if the menu choices seem to appear and
disappear based on whether someone is logged in via XDMCP or such.


I guess it could be configurable. Via a key in the Security section of gdm.conf
we could enforce that the power state of the machine can't be changed (if at
least one user is logged in) or it can be changed but the user is warned. It
would also be interesting to let a priviliedged user (via a password) do it
regardless of the configuration option.


Yes, this would be acceptable.  I believe some distros have a SecureMenu
patch which requires the user to enter the root password to gain access
to the system menu.  This patch may be worth tracking down since I think
it already implements what you suggest.


I think you aren't so much concerned in the number of users, but the
number of displays that GDM is currently managing.


I don't see why. I could open several flexiservers but have no one logged
in. That situation should still allow anyone to turn off the machine without
warnings.


That's true.  Still the GDM_SUP_ATTACHED_SERVERS returns the username so
you can check to see if the users are all the same user.  So that is how
you can get the user list you want.


You can tell how many displays are connected by looping over the
"displays" variable in the daemon.  Note the functionality of how
GDM_SUP_ATTACHED_SERVERS is implemented in the gdm_handle_user_message
function.  This gdmflexiserver command does what you want.


Yes, thanks. It seems I can get the logged in users with something like:

for (li = displays; li != NULL; li = li->next) {
        GdmDisplay *disp = li->data;
        if (disp->logged_in)
                nusers++;
}


Right.


We also should keep in mind what kind of users are we talking about. We can
distinguish between at least 3 kinds:

1. users that logged in such a way that gdm wasn't involved (this would require
   reading utmp I guess)
2. users that logged using gdm but remotely.
3. users that logged using gdm locally.

Dealing with just cases 2 and 3 would be OK.

You probably also care about flexible servers started by gdmflexiserver
and running on different VT's, or perhaps you are considering these the
same as #3.


To keep things simpler I guess we can just count the number of users as I
said above, which counts all #2 + #3 users AFAICT.

Anyway, after playing with the code for most of today I was able to get the
greeter to do what I want, but still... I mean, gdm's architecture is quite
broken IMHO. Let's see, we have:


Let's not jump to conclusions that it is broken already.  Let's discuss
a bit first...


1. "Opcodes for the highly sophisticated protocol used for daemon<->greeter
communications" + interruptions (and writing and reading to FDs)


These are messages that are going from the daemon to the greeter, not in
both directions.  These are used to control the state of the greeter.
These messages must be handled in a secure fashion.  In other words,
only the GDM daemon can send these messages.  If any program could talk
to the GDM greeter via this protocol, then people could easily implement
DoS attacks against the greeter if they had access to the machine
by telling the greeter to change state inappropriately (like resetting
to PROMPT over and over again would prevent a user from being able to
ever login).


2. "primitive protocol for controlling the daemon from slave or gdmconfig or
 whatnot"


These are messages that are going from a *valid* slave to the daemon.
These are messages that must be handled in a secure fashion since some
of them (HUP_ALL_GREETERS, SOFT_RESTART, etc.) would cause havoc if any
client program could send them.  So these must also be handled in a
secure way so that the daemon knows that these messages can only come
from a valid slave.


3. "The user socket protocol."


These are messages sent from any client program (even a user program)
to the GDM daemon to ask GDM for information or tell GDM to do something
that is okay (REBOOT, SHUTDOWN, etc.).  Some commands require the Xauth
cookie to ensure the user is who they claim to be.

Perhaps GDM could be rewritten to use less protocols, but the ones
that exist are for different purposes.  I suspect part of the reason for
this is that the slave programs are stateless and depend on the daemon
to tell them what should be displayed via protocol #1.  As the user
does things in the greeter, the greeter notifies the daemon via
protocol #2.  This is how state is currently maintained in GDM.
And as I mentioned before, protocol #3 is for non GDM slaves to be able
to talk to the GDM daemon.

That said, I should mention that there are some well known problems with
the current messaging system.  For example, bugzilla bug 336549.

So, if you think these protocols can be implemented in D-BUS and still
ensure the same degree of security, then I think someone should write
up a proposal of how things should be rewritten and send it to this
list for community review.

One potential problem, though, of having GDM depend on HAL/D-BUS is that
these add new dependencies.  Are HAL and D-BUS appropriate to be used
in root-owned daemons with the security requirements of GDM?  Have HAL
and D-BUS been audited to ensure that using them in programs like GDM
is appropriate?

Even if we can't use HAL/D-BUS for the above reasons, I'm sure the code
could be rewritten and improved natively.  After all, the messaging
needs of GDM aren't really all that great.


Which is already too many comunication channels for the same set of apps and
still, to halt and reboot we are using _exit() and waitpid()!


Yes, this is ugly and I'm sure the code could be rewritten and
improved.  It would be great if you would like to take a stab at this.


I understand that gdm manages a complex task and that probably many people
already touched the code (probably implementing their own ways to communicate)
but this makes it very difficult to change anything in a sane way. I'm afraid
that gdm is badly needing a major redesign, probably using newer technologies
like dbus and hal and with a single, powerfull interface between all the
pieces. I would like to help even if I don't know much about all these APIs
yet. Are there already any plans to engage in such a task?


I agree with you that a redesign of GDM's message handling system is
overdue, but there aren't plans at the moment to improve it.  If you
are interested in doing this sort of work, I'd be happy to help you
understand the code and help.

Brian
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]