linux-kernel - Re: AT_EXECFN not useful

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <48A61878.2060000@redhat.com>
Date:	Fri, 15 Aug 2008 16:59:52 -0700
From:	Ulrich Drepper <drepper@...hat.com>
To:	John Reiser <jreiser@...Wagon.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

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

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

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

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

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

> 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-----
--
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/