[pkg-fso-maint] Bug#525908: Bug#525908: Missing $SHELL variable is the problem

[Enrico Zini]

On Wed, May 13, 2009 at 09:35:29AM +0300, Andrei Popescu wrote:

> >         /* Prepare user session */
> >         g_setenv ("XAUTHORITY", d->userauth, TRUE);
> not set

I'd have assumed that it would be set by xinit, as that is what should
set up the X environment.

The variable should point to ~/.Xauthority which should contain the
authentication cookie to use to connect to the X server.

Here http://ptolemy.eecs.berkeley.edu/~cxh/sapub/Xsecurity.html it says:

  * Using Authority Files

  To turn on authorization file checking in an Xserver, the server is
  started with the -auth option. A typical xinit line would be:

    xinit -- -auth .Xauthority

There is more documentation in man X and man Xsecurity.

man xauth says:

  Normally xauth is not used to create  the authority file entry in the
  first place; xdm does that.

And if one doesn't use xdm? Looks like I have to look into the sources
of xdm. There is an auth.c over there, with lots of nontrivial code,
which eventually calls XauWriteAuth (for which there is a manpage). It
probably requires linking with libxau6, too.

Let's see what gdm does instead... funny that, grepping XAUTHORITY in
the gdm code shows a static get_parent_display function copied and
pasted in lots of sources... bad, bad, bad, but not relevant to us.

gdm seems to go through the various loops that xdm goes through as well.

Should I just copy and paste all of that? I'd rather not, because I
would have problems maintaining code that I do not understand. Plus, it
would only create yet another reimplementation of that bit, with
potential issues.

I'd rather lift code from xdm and create a little x-setup-xauthority
helper tool, which can be more easily audited and can be reused by
others.  Or maybe that's what "xauth generate" does?  If that works,
it's likely to be the best option.  Should that be done by nodm, or by
/etc/X11/Xsession?

Or what would be missed if we just do without it?

This looks nontrivial and should probably be turned into a new bug.


> >         g_setenv ("DISPLAY", d->name, TRUE);
> ok

This should be set by xinit.

> >         if (d->windowpath)
> >                 g_setenv ("WINDOWPATH", d->windowpath, TRUE);
> ok

This seems to be related to accessiblity and is somehow described here:
http://bugs.kde.org/show_bug.cgi?id=146537

I'm glad that, probably xinit, is setting that up.

> >         g_setenv ("USERNAME", pwent->pw_name, TRUE);
> not set

I'll implement that now.

> > #ifdef WITH_CONSOLE_KIT
> >         if (ck_session_cookie != NULL) {
> >                 g_setenv ("XDG_SESSION_COOKIE", ck_session_cookie, TRUE);
> ok

This is being set up as part of the environment variables provided by
pam. Actually, it is the only environment variable that pam provides in
my system.

> >         g_setenv ("DESKTOP_SESSION", session, TRUE);
> not set

This seems to be the kind of session (gnome, kde, lxde and so on) that
has been started by the display manager. I would think that, in the case
of nodm, it is the task of /etc/X11/Xsession (and related files, like
~/.xsession) to set this up.

> >         g_setenv ("SHELL", pwent->pw_shell, TRUE);
> not set as previously reported

I'll implement that now.

> > [..]
> >         /* Special PATH for root */
> >         if (pwent->pw_uid == 0)
> >                 g_setenv ("PATH", gdm_daemon_config_get_value_string (GDM_KEY_ROOT_PATH), TRUE);
> >         else
> >                 g_setenv ("PATH", gdm_daemon_config_get_value_string (GDM_KEY_PATH), TRUE);
> 
> set correctly for the user

This is probably done by /etc/profile, which is sourced by sh when
starting the X session: nodm runs "sh -l -c $NODM_XSESSION", and -l
tells sh to set up the environment properly.

> May 13 09:29:29 bixi console-kit-daemon[2136]: WARNING: Couldn't read /proc/2135/environ: Failed to open file '/proc/2135/environ': No such file or directory

console-kit-daemon is something that I do not know about, and I would
hope that it has nothing to do with nodm. I'll fix all the other issues,
then we can see what remains and if it has to with this
console-kit-daemon problem.


Ciao,

Enrico

-- 
GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini <enrico at enricozini.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-fso-maint/attachments/20090514/1fc367a7/attachment.pgp>