On 2025-09-26 10:27, Dag-Erling Smørgrav wrote:
This is a matter of security, not efficieny. You simply cannot get the
same security guarantees without AT_RESOLVE_BENEATH. You can achieve
the same result, but your code will be vulnerable to TOCTTOU races.
Yes and no. First, I'm planning a future patch to use AT_RESOLVE_BENEATH
if available, and this won't be an issue on FreeBSD once that happens.
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. This is true in both current
tzcode localtime.c (which has tzalloc) and in FreeBSD localtime.c (which
doesn't).
