After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 510469 - Not respect PATH complete..
Not respect PATH complete..
Status: RESOLVED FIXED
Product: gdm
Classification: Core
Component: general
2.21.x
Other All
: Normal normal
: ---
Assigned To: GDM maintainers
GDM maintainers
Depends on:
Blocks:
 
 
Reported: 2008-01-18 20:06 UTC by Jeremy Messenger
Modified: 2008-04-23 00:36 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22



Description Jeremy Messenger 2008-01-18 20:06:31 UTC
The GDM on FreeBSD, we have to chase in multi-files to get it respects the PATH. It would be nice if someone can make some changes in GDM by place PATH check in a file and check at once. Current, we had to add PATH in the startup script but GDM doesn't respect it complete. In the debug log shows (curent from GDM 2.21.4) that has PATH set in script without hack files in GDM:

Jan 16 16:57:14 mezz gdm-simple-slave[798]: DEBUG: GdmGreeterSession: greeter environment: PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
[...]
Jan 16 16:57:34 mezz gdm-session-worker[901]: DEBUG: GdmSessionWorker: set env: PATH = /bin:/usr/bin

The first one is correct and came from PATH in the startup script, but the second one is coming from one of file. I noticed that there has GDM_SESSION_DEFAULT_PATH in daemon/gdm-session-worker.c. It made me wondering why doesn't GDM use GDM_SESSION_DEFAULT_PATH for everything and even better put check on PATH in a place (a file). It would be easier for us and other OSs (Linux distro too) to not have to chase several files for that.

Without set PATH and hack in files, the GDM doesn't start GNOME session because it can't find binaries since the binaries are in /usr/local/(s)bin.
Comment 1 Brian Cameron 2008-02-04 23:20:45 UTC
Just to be clear, which binaries can't it find?  
Comment 2 Thomas Zajic 2008-04-19 07:40:18 UTC
The GDM_USER_PATH value seems to be broken in config.h, because ${exec_prefix} isn't properly expanded but applied verbatim instead:

[zlatko@disclosure]:~$ grep GDM_USER_PATH /usr/local/src/gdm-2.2*/config.h
/usr/local/src/gdm-2.20.5/config.h:#define GDM_USER_PATH "/bin:/usr/bin:${exec_prefix}/bin"
/usr/local/src/gdm-2.21.9/config.h:#define GDM_USER_PATH "/bin:/usr/bin:/usr/X11R6/bin:${exec_prefix}/bin"

So whenever you run ./configure with any --prefix other than "/usr", gdm is probably unable to find/run anything located elsewhere, eg. /usr/local/bin. My whole self-compiled GNOME installation lives in /usr/local, so this is obviously a bad thing. I fixed it by manually expanding ${exec_prefix} to /usr/local in config.h before running make.

This bug is present in gdm-2.20.x and gdm-2.21.x at least.
Comment 3 Brian Cameron 2008-04-21 23:54:37 UTC
I suspect the problem is with this code in configure.ac:

if test "x$real_gdm_prefix" != "x/" -a "x$real_gdm_prefix" != "x/usr"; then
    GDM_USER_PATH="$GDM_USER_PATH:${bindir}"
fi

What the code probably should do instead is the following

- expand bindir, check if it the value is already in the GDM_USER_PATH, and
  add it if not.
- if bindir isn't set, then check if $real_gdm_prefix/bin is already in the
  GDM_USER_PATH, and add it if not.

This would probably work better.  Or maybe GDM shouldn't try to be smart about adding the prefix to the GDM_USER_PATH at all.  Note configure does support a "--with-post-path" option so if you want to add additional directories to the default PATH you can do so by specifying this configuration option.  It might be best to just require people to do this all the time if they want to install GDM to a non-default location.

Thoughts?  I'd happily accept any patch to fix this issue.
Comment 4 Thomas Zajic 2008-04-22 18:55:56 UTC
The --with-post-path solution seems perfectly acceptable, IMHO. Given that the existing setup didn't work at all for --prefix != "/usr" anyway, I doubt anyone would actually notice if GDM simply stopped trying to be smart about it. ;-)

It's better than having a broken path component hardcoded into the executables anyway, even if it's only for cosmetic reasons.
Comment 5 Brian Cameron 2008-04-23 00:36:52 UTC
Thanks.  I removed the offending code that was incorrectly trying to append ${prefix}/bin to the DefaultPath and RootPath so now users will need to use the --with-post-path configure option to add other directories to DefaultPath and RootPath.  Or if someone wants to provide a patch to make the code smarter, that would be great too.  Anyway closing this bug now.