Date:	Thu, 14 Aug 2008 22:10:23 -0700
From:	John Reiser <jreiser@...Wagon.com>
To:	Ulrich Drepper <drepper@...hat.com>
CC:	Linux Kernel <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: AT_EXECFN not useful

Ulrich Drepper wrote:
> I've just removed the support for AT_EXECFN again from glibc.  The
> information isn't useful because the path name isn't normalized.  I.e.,
> it's not the actual binary path if symlinks are followed during the
> resolution.  This makes it unusable for the $ORIGIN handling.

AT_EXECFN does provide one actual path, namely the one that was passed
to namei.  This path works for some uses and some cases, including some
uses and some cases of $ORIGIN.  The path which sometimes is revealed
by readlink("/proc/self/exe",) also works for some uses and some cases,
including some uses and some cases of $ORIGIN.  Neither /proc/self/exe
nor AT_EXECFN works for all uses and all cases.

> This is on top of the problem with relative paths.

Please provide a statement or citation which describes "the problem with
relative paths."

> Unless somebody has another use case where this is useful I suggest
> removing AT_EXECFN support again.  It's just superfluous work and memory
> use.

AT_EXECFN is useful when readlink("/proc/self/exe",) disappears
yet the actual pathname that was passed to execve() still is accessible.
Users of the UPX program compressor (http://upx.sourceforge.net) have
asked for such a feature several times.  The UPX runtime decompressor
creates an address space which is difficult to distinguish from
the address space which would result from an execve() of the original,
uncompressed file.  In particular, the UPX runtime decompressor unmaps
all pages of the compressed file, which triggers the removal of the /proc/self/exe
symlink.  As a palliative, UPX records readlink("/proc/self/exe",) in an environment
variable.  If the UPX decompressor is not the first to run after execve(),
then this palliative can fail in the same way.

One time-honored use of "the path that was specified to execve"
is to lookup the debug symbol table for the current main program
(for example in catching SIGSEGV and filing an automatic bug report with
traceback information) under some time-honored schemes for static binding.
Another use is to consult a default static database which has been appended
to the executable itself (usually with an index near the end of the file.)
Although such usage can be defeated, nevertheless in practice many installations,
applications, and users successfully avoid the problems.  In particular,
uses which do not depend on visiting other directories often work just fine.

AT_EXECFN is useful in documenting the kernel's actual behavior of
putting the pathname argument to execve() into the new address space.
Having a designated slot in the the aux vector also provides a convenient
place for a virtualizer to adjust and communicate this path in ways that
are appropriate to the virtualization.

> Of course I wouldn't object to a real implementation which always gives
> me the full, normalized path name of the executable...

Multiple hard links create multiple normalized path names, possibly including
paths that have the same endpoints but which differ in arc length.  Which
of these multiple paths is to be blessed as "the full, normalized path"?

The case of mounting another filesystem on top of an intermediate directory
in "the path to the executable" may cause there to be zero "full, normalized
path name"s to the current main executable.
Depending on the relationship of mount point, working directory, pathname to
execve, and the text which surrounds $ORIGIN, then a simplistic method of
textual select+concatenate may succeed despite the failure of a method
involving detailed normalization.

These cases illustrate that there can be problems in asking for too much
when dealing with $ORIGIN.  AT_EXECFN provides some actual historical data
that may be useful as a hint, especially when the kernel drops the
/proc/self/exe symbolic link.  This hint is enough for some current use cases.

-- 
John Reiser, jreiser@...Wagon.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists