On 14/11/13 01:10, Leo Antunes wrote:
> I'm consistently getting the
> issue described by Gabriel Mainberger, namely that gdm gets the wrong
> XDG_RUNTIME_PATH and fails to start. But interestingly it only happens
> if I restart gdm.
libpam-systemd derives the XDG_RUNTIME_PATH from the "loginuid", which
was originally part of the audit framework. The loginuid was originally
intended to answer questions like "yes, I know this process is root, but
who is it really?" to provide an audit trail:
* /sbin/init has no loginuid (-1)
* a process can change its loginuid from -1 to its own uid
* otherwise, processes cannot change their loginuid
* processes that handle an interactive login are expected to change the
loginuid from -1 to the uid of the logged-in user
Conceptually, system daemons like gdm, ssh, Apache, Exim ought to have
loginuid -1: they're part of the OS, not a user (nobody "logged in" in
order to use them). If a daemon handles logins (like gdm and ssh), this
leaves it able to change its child's loginuid from -1 to the correct value.
Under systemd (or probably Upstart too), this is fine: service(1) and
similar tools just do IPC to init rather than launching the daemons
themselves, and the new gdm is started by init, so it has loginuid -1 as
desired. However, under sysvinit, there's no IPC interface by which this
can happen, so invoke-rc.d/service/etc. start the daemon themselves.
This results in the parent/child hierarchy conceptually being something
like this:
init
\- getty or something: uid 0, loginuid -1
\- bash as root: uid 0, loginuid 0
\- invoke-rc.d: uid 0, loginuid 0
\- ...
\- gdm: uid 0, loginuid 0
\- gnome-session: uid gdm3, loginuid 0
or:
init
\- getty or something: uid 0, loginuid -1
\- bash as a user: uid 1000, loginuid 1000
\- su: uid 0, loginuid 1000
\- invoke-rc.d: uid 0, loginuid 1000
\- ...
\- gdm: uid 0, loginuid 1000
\- gnome-session: uid gdm3, loginuid 1000
Even after gdm daemonizes and re-parents to init, its loginuid remains.
That's sort of the point of loginuid.
(This sort of "process environment leaking from parent to child"
situation is one of the reasons systemd/Upstart are better than the
"sysvinit + constellation of shell scripts" approach to init...)
The same thing breaks many tools when run under su (e.g. see
<https://bugzilla.redhat.com/show_bug.cgi?id=753882>). There's some
recent discussion on that bug: Ubuntu developers have been hit badly by
it too.
S
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
