On 2025-09-29 09:05, Dag-Erling Smørgrav wrote:
The goal is to allow TZ to point to anything inside TZDIR, either absolutely or relatively, and nothing else, in the setugid case; there's also a check that handles the weird-but-not-unheard-of case where TZ points to TZDEFAULT (I've encountered downstream code that sets TZ to ":/etc/localtime"; I don't know why, and I'm afraid to ask, but it needs to work). We previously had something lifted from OpenBSD which would simply reject anything that contained a dot. This seemed overly restrictive, so I wrote what we currently have instead.
The old OpenBSD approach of rejecting anything containing a dot was inspired by a tzcode change contributed by Arthur David Olson in 1986[1]. In 2018 I noticed the same issue you did - that rejecting anything containing '.' was too restrictive - and changed tzcode to reject only pathnames containing a ".." file name component[2]; this was later picked up by NetBSD. The OpenBSD maintainers noticed the same issue in 2022, and changed their implementation to reject all strings containing "../"[3]. The tzcode and OpenBSD approaches both work well enough in practice; the tzcode approach is slightly more generous, as it allows bizarre settings like TZ="Hello../World", but that's not a significant difference. The avoid-".." approach has been used for quite some time and I know of no security problem with it. I keep asking about this because if there is a practical security problem with the approach, it's important for OpenBSD, NetBSD, tzcode etc. to know it so that we can fix our code.
It does add a couple of syscalls, but I can't think of an alternative that doesn't add even more. The alternative used in current tzcode[4] (assuming OPENAT_TZDIR is 0) handles all the cases mentioned in the above-quoted remarks (setugid, TZ=":/etc/localtime", TZ="/etc/localtime", TZ="/usr/share/zoneinfo/America/Los_Angeles", etc.), and it does so without using openat + AT_RESOLVE_BENEATH. Again, if there's a problem with it I'd like to know.
[1]: https://github.com/eggert/tz/commit/2c592c94b83514b80aabeca638ea7afde5f69436... [2]: https://github.com/eggert/tz/commit/6c9af485e113f60d32e47ff64ef22423ccbdc496 [3]: https://github.com/openbsd/src/commit/a88d58b8033c36ffc70b16c55fd0624a20c4f0... [4]: https://github.com/eggert/tz/blob/997441bed2d4832e0ee5f9effc037986b725059c/l...
I'm starting to doubt your good faith here, Paul.
I don't see why, as the questions are genuine and are based on some research. It sounds like there's been some miscommunication on my end. If so, I apologize.