On 2025-09-26 11:55, Paul Eggert via tz wrote:
On 2025-09-26 10:27, Dag-Erling Smørgrav wrote: Second, even platforms lacking AT_RESOLVE_BENEATH get equivalent security guarantees, because we can trust the contents of /usr/share/zoneinfo (if we can't trust that directory, we have bigger problems than those fixable by AT_RESOLVE_BENEATH!) and tzcode's localtime checks for ".." in relative pathnames (I'll arrange for this check to be optimized away on platforms with AT_RESOLVE_BENEATH).
* Although FreeBSD takes some steps to treat TZ settings the same regardless of whether they come from the TZ environment variable, it doesn't take this idea to its logical conclusion. It seems to me that it's better to not care where the TZ setting came from, as that's easier to document, understand, and maintain, so the attached patches do that.
That's just wrong. As a setugid program, I can't trust TZ because it was provided by an unprivileged and untrusted user, so I must defend against attempts to break out from TZDIR. I should however be able to trust TZDEFAULT, even if it points to something outside TZDIR, because TZDEFAULT is controlled by the administrator, not by an untrusted user.
Ah, I should have mentioned that TZDEFAULT (default "/etc/localtime") is a special case: its is trusted regardless of whether it came from the TZ environment variable or from tzalloc. If you do not allow data file paths outside TZDIR, how do we test zones in the packaged build or staging directories, or custom or patched zones in our dev directories?
Is it not better to apply the same untrusting attitude about TZ to all external data, regardless of what you believe about the source, which may have been compromised? This seems to be how exploits are elevated from messing with relatively obscure files which are misconfigured, accidentally or maliciously! I never understood why effectively constant data files are installed with user write privileges, where read only might slow attackers a smidge, and may have to be used on systems which do not really support POSIX permissions; more especially if that is made a checked security condition! -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retrancher but when there is no more to cut -- Antoine de Saint-Exupéry