The trouble with symbolic links

Posted Jul 12, 2022 3:26 UTC (Tue) by neilbrown (subscriber, #359)
In reply to: The trouble with symbolic links by ma4ris5
Parent article: The trouble with symbolic links

> Here is one conceptual way to _open up a file for read_ in a safe way

Or you could use realpath() to expand all the symlinks, validate the path in whatever way you care about, and then use openat2() with RESOLVE_NO_SYMLINKS.
If any symlinks have been inserted into the path, the open will fail.

(requires Linux 5.6 or later, glibc doesn't have a wrapper)

to post comments

The trouble with symbolic links

Posted Jul 15, 2022 6:10 UTC (Fri) by ma4ris5 (guest, #151140) [Link]

Thanks for the tip. Sounds sane: First remove symbolic links, then expect that there are no symbolic links.

With all uncertainty, the approach that I mentioned, is to first hold file descriptor to something
that is nearest of the goal operation.
File descriptor is stable (Kernel guarantees that), so holding it prevents many kinds of race conditions.
Then validate the opened file descriptor based on trusted sources for security reasons.

After gaining trust for a folder file descriptor, use it in safe ways (for example create a file with symbolic links turned off).

So from Samba developer, /proc/self approach works for solving the real path for validation:

fd = openat(-1, "/bin", O_DIRECTORY); /* fd = 3 */
resolved_path = realpath("/proc/self/fd/3", NULL); /* resolved_path="/usr/bin" */

"/usr/bin" is safe, so fd 3 can be used for following operations.