On Wed, May 13, 2009 at 09:35:29AM +0300, Andrei Popescu wrote:
> > /* Prepare user session */
> > g_setenv ("XAUTHORITY", d->userauth, TRUE);
> not setI'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 <[email protected]>
signature.asc
Description: Digital signature
_______________________________________________ pkg-fso-maint mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/pkg-fso-maint
