-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Reiser wrote:
quoted text
> 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.

It is not possible to use the raw path provided.  One _always_ would
have to canonicalize the path (call realpath etc).  That's terribly
expensive and it requires that nothing in the path hasn't changed.


quoted text
> 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.

The information is always correct when it is provided.  If the file goes
away then the AT_EXECFN use case also fails since realpath fails, or
worse, provides wrong data since it's using newer files.


quoted text
> Neither /proc/self/exe
> nor AT_EXECFN works for all uses and all cases.

The only case where AT_EXECFN has an advantage is when /proc isn't
mounted.  That's not supported anyway because this is the only way for
many things how the kernel exposes data (sysctl is deprecated) and we
need this information in many places.


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

If the program is started via a relative path AT_EXECFN has this string.


quoted text
> AT_EXECFN is useful when readlink("/proc/self/exe",) disappears

As said above, in that case it isn't useful either because one cannot
verify the value.

I've removed all support for AT_EXECFN and won't put it back since there
is no use case where it has any advantage.  realpath() is terribly slow.

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkimGHcACgkQ2ijCOnn/RHS8LACfdknhKbYiaKo8fe4hFgRq3VZn
emYAn2vdy7Jddzia7m6hLj6nMlnU0HiO
=NJxG
-----END PGP SIGNATURE-----
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/