Re: [gdm-list] Per-user session scripts for GDM defaults?

[Jouko Orava <joorava iki fi>]

> > I was hoping to convince a developer to try this themselves,
> > so they'd push it thorough.
>
> Good luck!  Sometimes just suggesting an improvement or highlighting
> a bug is enough to get someone to do the work, but not always.

True. Even though I do happily use many parts of Gnome (but not the
entire desktop), I've thus far not participated; I'm a fanatic proponent
of maximum configurability, something which is perceived to be less than
important for Gnome projects.

> I understand.  Really there are two issues:
>
> 1) The ability to make it easier for sysadmins to customize the
>    scripts by adding a level of indirection.  For exapmle, if GDM also
>    ran a script that the sysadmin could provide, then this would allow
>    sysadmins to run their own code without having to modify the default
>    scripts.

Fully agreed.

> 2) The ability to add a hook for users to run user-defined scripts.
>    While there are cases that this would be useful, this would need
>    to be implemented with proper security in mind.  It would not
>    be good to run the user-defined scripts with any inappropriate
>    privileges.

Fully agreed.

>                Getting this right might be some work.

No, not really, especially not if you extend
daemon/gdm-slave.c:gdm_slave_run_script().

First, you fork. In the parent, wait for the child to finish.
In the child, close all descriptors, and create a new session
(via setsid() or setpgid()) to shield the parent from any
unwarranted signaling).

Then you fork again. Parent is used for privileged scripts,
and child for unprivileged ones. The child will drop privileges
using preferably setresuid() and setresgid(), because that way
the child cannot regain root privileges prior to exec()ing,
even if a security hole is found.

Then, the two processes will create their own sessions,
scan for the script files they should execute.
For each script, they must fork, and in the child,
create a new session, open stdin from /dev/null,
and open stdout and stderr to a log file or to /dev/null.
Then, exec the script file.

If you wait for each child at this point, you'll run the scripts serially.
I think it would be better to just save the pids, and wait
for all at once, so that the scripts are run in parallel.

In fact, it would be very easy to set up a timeout (alert()),
preferably an easily configurable one, to kill scripts that run for
too long, and easily understood by users and sysadmins.

Finally, it is easy to gather the exit status codes,
and examine them as a set, to decide whether they were
run without problems, with minor issues, with fatal flaws,
or if some of them had to be killed.

After deciding on this, the child will just exit with the
suitable status code, which the original fork()ed process
will catch.

The original fork()ed process then decides by looking at the
privileged and unprivileged results, and tells the original
GDM whether the scripts were run successfully, or if a failure
occurred.

You can complicate this by adding further information flow,
but the above should be very reliable, easy to understand,
and very, very robust, in my experience.

Let me know if a patch would be appreciated.
I'd need a few days to get familiar with the code and style, first.

> Note that solution #1 can also provide the solution for #2 since
> the sysadmin can add a hook to run scripts in the user's $HOME
> directory (including dropping privilege) if desired.

Sure. The only problem is to make sure distributions realise the purpose,
and don't accidentally disable or remove the functionality.

For example, distributions might misuse the feature for internal purposes,
such as xsplash or others, making it difficult for end-sysadmins.
Remember, this is my original problem.

> > For improved security, one could even redirect stdin/stdout/stderr
> > and run the scripts in a new session using setsid. That would
> > completely detach the scripts from gdm.
>
> I wouldn't call this "improved security", I would call it a
> "requirement" that any user-defined scripts be run with user privileges.

Running the scripts in a new session shields the parent GDM process
from signals sent by the children; it is a separate measure from
dropping root privileges.

I believe that without starting a new session (AKA a process group),
the child process can send signals to the parent process,
simply by broadcasting them -- that is, by sending them to its own
process group.

Whether or not signals sent from scripts can harm GDM,
I do not know; I don't know GDM structure well enough yet to say.

> One issue with running user-defined scripts is to ensure that you
> properly manage the situation where the user-defined scripts cause
> problems with the login process.  GDM should make reasonable efforts to
> recover and report any issues to the user.

Extending daemon/gdm-slave.c as above, makes it easier.
GDM would know if the failed or stuck script was a privileged
or unprivileged one, at least.

> For example, what happens if the user-defined script hangs?  If this
> causes GDM to hang, this would be a problem.  Opening the door to user
> defined script opens a lot of concerns that will need to be thought
> about and discussed, I think.

A suitable timeout -- especially one which is easy and logical for users
and sysadmins to understand (because it is in real wall clock time,
and not a part of a composite timeout) --, would be enough, I believe.

Are there any messages GDM (child processes) should send when each
script is started/completed, that user splashes could observe,
and let the user know? Or would logging be enough?

But I do agree with you. Such changes, even if proven sensible and safe,
would drastically change the way GDM processes its startup scripts.

Considering the recent big changes in GDM, is that wise?
Do the benefits outweigh the risks?

I originally suggested the change to the defaults,
only because they do not change anything, unless the admin
specifically sets the scripts up.

This is getting much bigger.

> I think there will be a fair bit of discussion and work involved before
> this gets accepted upstream.  It is more likely this will get done if
> the issue is raised as an RFE in the "gdm" category of
> http://bugzilla.gnome.org/.
>
> Bugzilla is much more useful for reviewing code, raising issues, and
> discussing a proposed idea than email.

I do respect the project and your work, so I'll do just that,
	Jouko