I don't see how any part of gdmsetup could be considered as user editable.  All
the configurations in gdmsetup are system level configurations and therefore
should require root access to modify.  For instance, if I'm the sysadmin, I
don't want a user to be able to add there own login screen themes.  As for the
Home bookmark, it goes to /root because elanthis isn't the one running gdmsetup,
root is.

Maybe what we need is a system to allow more than just root, access to gdm? 
Should gdm have a section much like say "Xcdroast" uses where root specifies
what users other than root are allowed access to modifying your system with
gdmsetup?

It has nothing to do with the actual backend workings of GDM.  It's the fact
that the front-end itself behaves incorrectly on the user's desktop because the
front-end is running as root, which results in it having a different theme,
behaviour, and other settings than other apps, which breaks the consistency and
over-all cohesiveness of the desktop.

THe fact that "root" is running the process is an implementation detail of the
security model.  It should not be adversely affecting the GUI.  It shouldn't be
something the user/administration has to know at all, other than the fact that
they have to enter a root password.  Well, MAYBE they have to enter a root
password... maybe gdmsetup was launched using a sudo-like system (a la Ubuntu).

By making the front-end run as the user, you ensure that the GUI looks and acts
consistent with all the other apps on the current desktop.

Yes, it's bad that gdmsetup runs as root.  You really shouldn't write GTK+
programs that are intended to run as root.  It would be better if this were
rewritten so that gdmsetup talked to the daemon, perhaps by using a
gdmflexierver command, to deal with actually changing the gdm.conf file.  

The hard part is figuring out the best way to authenticate the user with the
root password so that the configuration file can only be changed by someone who
has root authority.  We obviously don't want any user to be able to change the
configuration.  It would be useful to hear if anybody has any suggestions about
the best way to manage this.

See the section I wrote on PrivilegedOperations on live.gnome.org.  That's the
approach _I'd_ take, although my opinion is pretty worthless around here...

Generally, the back-end would be invoked just like the current front-end is
invoked on most distros - using gksu or console helper or something equivalent.
 The front-end would initiate the launching of the backend this way and have
setup some pipes/sockets for communication.  Thus the backend is launched and
authenticated using whatever is appropriate for the system and the front-end
runs as the user that launched the application.

Having a small wrapper library and API for managing this in a generic fashion is
what the PrivilegedOperations idea is all about.

Sean,
In no way was I trying to say your opinion was wrong or not welcomed.  I was
just trying to say that "I didn't see it", and that I didn't understand what was
wrong.  You have helped clarify what is wrong.  I appreciate that.  I'm sorry if
you took offense as to what I said.  I'm not very experienced at linux/oss/gnome
software development  (although I've been using it for 9 years) and I'm learning
as I go.  I was in no way trying to put your statements down, but trying to
explain what I saw and trying to say I didn't understand what the problem was. 
I'm sure the gdm developers appreciate your help as much as everyone else that
contributes.

No no no.  I wasn't saying YOU were putting me down, sorry.  That was just the
end-of-term anxiety mixed with frustrations over some other non-related
GNOME/FreeDesktop.org stuff.  Totally nothing you did.  Sorry.

I also recall that GNOME Setup Tools has something similar to my
PrivilegedOperations idea, although a little less universal - you might try
seeing if that code can be reused for managing the GDM backend/frontend split.

I went ahead and read your article and downloaded the system-tools source
yesturday (setup-tools new name).  I haven't had time yet to look through the
system-tools source.  But I'll get there eventually.  Thanks Sean.

For anyone else that wants to look into this...
http://www.gnome.org/projects/gst/index.html

*** Bug 126050 has been marked as a duplicate of this bug. ***

The goal here should be to end up with a GUI program (gdmsetup) that runs as the
user, and a backend program that actually writes the new configuration info to
the file.  As has been discussed, the hard part is that we want all this to only
work if the user has entered a valid root password first.

One thing to keep in mind is that the GDM daemon already has a lot of
infrastructure that should make it possible to get this working without
requiring new dependencies (such as sudo or libgnomesu).  The GDM daemon is
already running as root and already has plenty of logic inside for doing things
like asking for the root password.  Why can't the daemon itself be the backend
program?

One way this could be resolved is to add a new gdmflexiserver command that tells
the daemon to pop-up a dialog window asking the user for the root password.  The
logic for this popup is alrady in the daemon, and is already used when launching
gdmsetup from gdmgreeter, so it shouldn't be too hard to hack the GDM daemon to
be able to launch a GUI like this when it receives a new gdmflexiserver command.

Once this is added gdmsetup could call this new gdmflexiserver command when it
is launched; and if the user types in a valid root password, then the daemon and
gdmsetup could establish a pipe that will allow gdmsetup to tell the daemon what
values in gdmconfig need to be updated and with what values.  When I say "pipe"
I don't want people to think I mean anything specific.  This could be
implemented with a sockets pipe, but there are probably other communication
mechanisms that could also work.  One nice thing about this solution is it moves
the logic for actually writing the config file into the GDM daemon which is
probably a better place for it.

In other words, any program could call the new gdmflexiser command.  This
command will cause the root password to be requested in a pop-up dialog on the
display where gdmsetup is running.  The program calling the gdmflexiserver
command will be free to establish a connection with the gdm daemon to start
editing the config file only if a valid root password is entered.  So other
programs besides gdmsetup could also edit the gdm config file this way, but only
if they first enter a valid root password in the pop-up.  This seems okay to me.

I think a solution that works like this would be probably easier to implement
than hacking GDM to depend on techniques like sudo or libgnomesu which require
setup to work.  Also, solutions like these tend to not always work on all
platforms, causing headaches.

Care will need to be taken so that *only* the user who enters the valid root
password can use the pipe that allows changing gdm.conf options but I think this
could work if gdmsetup opens a socket it starts listening on, runs the new
gdmflexiserver command telling the daemon "here is my socket, start talking to
me on this socket and let me know if the user entered a valid root password or
not.  If the user did, then the daemon can let the gdmsetup program continue
talking on the socket to change configuration data.  If the user did not enter a
valid password, the daemon can let the gdmsetup program know "too bad" and close
the socket.  gdmsetup could then pop-up a dialog asking the user if they want to
try again.

How does this sound?

Another thing to consider is that this could be made into a general utility for
asking for password validation that setuid/setgid programs could use in general.  

It might be nice if you could tell GDM via a flexiserver command "please pop-up
a window that will validate user x" and would return TRUE if they entered the
right password and FALSE otherwise.  This is slightly different, but would
probably be useful for programs that want to be setuid or setgid but want to get
validation before allowing the user to do something.  It would mean that various
programs could use GDM to do this rather than using sudo or libgnomesu, etc.  It
probably doesn't make sense for gdmsetup to use this additional command since we
don't really want gdmsetup to be setuid/setgid in the first place.

gnome-system-tools already has code for asking for root passwords and such. 
This problem is already solved.  It's more just an issue of making gdmsetup use
it than it is of finding a solution for asking for root passwords and such.  Not
to mention that with gnome-system-tools, a backend change to that framework
should allow automatic drop-in of sudo or console-helper or whatever
authentication system the admin is using without needing to change backends or
frontends.

Thanks Sean.  It's good to know that gnome-system-tools can be used as well and
that it provides this sort of service already.  Though if we added this sort of
feature to GDM couldn't GDM also be a pluggable backend for gnome-system-tools
if a sysadmin didn't want to use sudo or console-helper?

There are some advantages to coding this inside of GDM:

+ Since GDM is a login program that is also used by non-GNOME users, it is nice
  to keep dependencies to a minimum.

+ GDM already has much of the functionality needed to provide this feature 
  already (ability to popup dialogs asking for root password, ability to
  authenticate username/password entry), sockets protocol for daemon/slave 
  communication.

+ If we were to use gnome-system-tools that would mean that we would need to
  add another binary to GDM.  gdmsetup would need to talk to a backend 
  program that actually manages interfacing with gnome-system-tools and
  writing to the (writable-only-as-root) gdm.conf file.  I'm assuming that it 
  would not be possible for the GDM daemon itself to be the backend program 
  that gdmsetup would be able to use.  Correct me if I'm wrong.

+ It seems cleaner to move the "writing to the GDM config file" logic into 
  the GDM daemon rather than somewhere else.

However, it could work either way.  I would accept a patch to fix this 
problem using either gnome-system-tools or managing this internally.  I'm 
just highlighting some of the  advantages of handling this internally in 
GDM.

Hmm, what is the _real_ advantage of making GDM the backend?  Given that GST
exists, I don't see code reduction as a real reason, since the code exists and
is already a part of GNOME anyhow.  Making GDM a backend for configuration
editing doesn't add anything over what we have now.

Also keep in mind that making GDM a backend could be a security problem. 
Currently, GDM only needs privileges to read its configuration file.  Granting
privileges to write the configuration file is something that should probably be
avoided.

Additionally, keep in mind the huge complexity of making communication with a
running daemon secure on both local and remote configuration scenarios.  GST
simply launches the backend using su/sudo/consolehelper/etc., where-as using the
GDM daemon would require the creation, auditing, and maintenance of a custom IPC
mechanism that allows local and remote verification of user authority to edit
the GDM configuration.

So far as having an extra binary, keep in mind that it's certainly possible to
share code between the configuration backend and GDM itself through a private
shared library.  If you're worried about code duplication or bloat, I don't
think that it's really going to be a problem.

Well, it's not completely correct to say that GDM doesn have privilegdes to
write to the configuration file.  The GDM daemon runs as root, and therefore has
priviledges to do anything it wants.  The only thing preventing the GDM daemon
from being able to write to the configuration file is that it currently doesn't
have logic coded to do so.

You are correct that adding such logic to the GDM daemon could open up some
security concerns.  If such code were added to the GDM daemon, it would need to
be added in a way to ensure that it would only be possible to write to the
configuration file if the user entered a valid root username/password.  However,
it is hard to write bug-free code, so perhaps it is safer/better to use a
different mechanism such as gnome-system-tools.

As I said before, it could work either way and I would accept a patch to fix
this problem using either technique.  As you point out, using gnome-system-tools
would probably be less work since the creation, auditing and maintenance of a
custom IPC mechanism sounds like more work.  

Thanks for talking this through with me, Sean.  I think we have a better
understanding of how to approach fixing this bug now.

After thinking a great deal about this, I think the right way to fix this problem would be to do the following:

1) Fix gdmsetup so that it doesn't actually write to the custom configuration 
   file.  Instead it should internally cache the changes and submit them all
   in one go.  Note bug #404891 is changing gdmsetup so that the changes are
   applied by hitting an Apply button rather than causing them to update one
   at a time.

   However, even after that fix, gdmsetup is still writing to the configuration
   file after each change, it just doesn't update the daemon until the Apply
   button is hit.

   Therefore, it would be necessary to further change gdmsetup so it doesn't
   modify the file as you change events, but instead caches the changes and
   applies them at once when the Apply button is hit.

2) Modify gdmsetup to call a program like sudo or gksu (probably should be
   configurable via configure script argument or by a GDM configuration option)
   and the command to actually modify the configuration file would be executed
   via sudo or gksu when the Apply button is hit.  This might require writing
   a helper program that takes some output from gdmsetup and actually does
   the modifications to the configuration file.

   In this case the gdmsetup GUI program itself would run as the normal user 
   when run in a user session or as the "gdm" user when run from the login 
   screen (this would require a minor change to daemon/gdm.c to no longer run 
   gdmsetup as root but instead as the gdm user).

   This would make gdmsetup slightly more annoying to use, since you would 
   have to re-enter the root password each time you hit the Apply button.

   However, the advantages very much outweigh any annoyances.  This is better
   because it limits the elevation to root privilege to *only* the code that
   needs it (to write to the configuration file), so this would limit the
   opportunities to exploit the root user in the GUI code.

   Probably the main usability advantage is that this would fix gdmsetup so
   that it is accessible.  The a11y infrastructure only is responsive to
   programs where the GUI runs as the user.  So when you launch the GUI as
   root (like most distros do, by putting sudo gdmsetup in the 
   gdmsetup.desktop file), then this program is non-responsive to any AT
   (Accessible Technology) programs like orca.  Fixing gdmsetup GUI to run
   as the normal user would resolve this.

   I think this would also fix bug #407008 which causes GDM to hang if you
   try to run gdmsetup with accessibility turned on.  Note GDM in SVN head
   turns off the "Configure Login Manager" choice when a11y is turned on to
   avoid users getting into this hanging situation.  So when this is fixed
   (or when testing to see if this fixes that problem), then this hack will
   need to be removed so you can launch gdmsetup when a11y is turned on.

3) I'm not sure, but some people might still want to run gdmsetup as root
   (if, for example, there is no sudo or gksu type program available).  It
   might be nice to be able to configure gdmsetup to work in its current way
   if desired.  Unless someone pipes up and says that they really want it to
   work this way, I'd suggest we not do this and only add this sort of 
   configuration if requested.

As I mention, this depends on bug #404891 being fixed, so I think I'll wait to do this until that issue is resolved (hopefully soon).

If gdmsetup ever comes back, it should probably use policykit

Thanks for taking the time to report this bug.
However, you are using a version that is too old and not supported anymore. GNOME developers are no longer working on that version, so unfortunately there will not be any bug fixes for the version that you use.

By upgrading to a newer version of GNOME you could receive bug fixes and new functionality. You may need to upgrade your Linux distribution to obtain a newer version of GNOME.
Please feel free to reopen this bug if the problem still occurs with a newer version of GNOME.