Bug 171164 - Reference to /usr/X11R6/bin/xauth
Summary: Reference to /usr/X11R6/bin/xauth
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: pam
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-10-18 21:37 UTC by Bill Crawford
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version: pam-0.80-13
Clone Of:
Environment:
Last Closed: 2005-10-27 08:54:07 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Bill Crawford 2005-10-18 21:37:10 UTC
Description of problem:
A reference to this path is hardcoded in pam_xauth.so

I did notice that a "xauth_path" parameter can apparently be passed, but this
needs to be changed to work with the newer (modular) xorg.

It isn't clear to me how easy it would be to use this parameter; would it not
need to be specified in every pam config (i.e. all packages that use pam would
need to be changed?)

Comment 1 Tomas Mraz 2005-10-20 07:57:40 UTC
Good catch. Of course it isn't plausible to modify all the configuration files
containing pam_xauth. I think the only solution is to add more than one
hardcoded paths to the xauth executable and try to find it among them. I suppose
that with modular X.org it can be found in /usr/bin/xauth? Or what are the other
possibilities?


Comment 2 Bill Crawford 2005-10-20 10:05:02 UTC
I'd go for recoding using libXau directly ;) but yes, /usr/bin should be the way
to go now.

Make it configurable at build time (--with-xauth-path or something) so you can
still build for pre-FC5?

Comment 3 Tomas Mraz 2005-10-20 10:34:26 UTC
I think that there should be more than one path in the binary so it is not
necessary to recompile PAM if the path changes.


Comment 4 Mike A. Harris 2005-10-20 17:37:47 UTC
I think I agree with Bill in comment #2, however that may or may not be
a large amount of work.  I'd also say that that is something that should
be done upstream rather than locally if we went that direction (wether
it was someone at Red Hat or someone in the community who did it).

For calling xauth directly, I would recommend searching the system PATH
for the binary, and building in a default PATH if one isn't set.  It
should search /usr/bin/xauth first, then /usr/X11R6/bin/xauth.

Note that it is possible to build all of X both in the monolithic Imake
tree, and the modular autotooled tree and have it install into any location
other than /usr or /usr/X11R6.  In other words, xauth could be theoretically
in /usr/local/bin or /opt/bin or /opt/X11R6/bin or ...

So, hard coding things like this is just bad programming IMHO.  There should
be a way to set it at both compile time and runtime.  Or as Bill suggested,
avoid that and use libXau directly.

Having said that though, I'll be happy enough with any fix or workaround,
so long as we can eliminate the /usr/X11R6 hierarchy and all dependencies
on it.  ;o)

Hope this helps.


Comment 5 Tomas Mraz 2005-10-20 19:53:41 UTC
I've already commited a fix to upstream CVS. It is not ideal but it should be
enough. The problem with searching the PATH is that it could be modified by
malicious user and so it is probably not safe to use it in setuid binaries.
However part of the fix allows easily adding a path where xauth is through a
build time option to configure.

So in the fixed pam_auth there are:

1. hard coded default search paths - /usr/X11R6/bin/xauth, /usr/bin/xauth and
/usr/bin/X11/xauth
2. a) ./configure --with-xauth=/path/to/xauth
   b) if --with-xauth option is not specified a search of xauth binary in
configure script using the build-time PATH is performed and if it is found it is
prepended to the hardcoded default search paths
3. run time configurability as in the existing pam_xauth (not too useful)

That should be enough or not?

Comment 6 Mike A. Harris 2005-10-20 23:44:04 UTC
Our xauth will be located at /usr/bin/xauth for FC5 and later.  Any solution
which pam finds it there works for me.  Black box thinking.  ;o)


Note You need to log in before you can comment on or make changes to this bug.