This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: ~/.localtime ?
- From: Andreas Jaeger <aj at suse dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: "libc-alpha" <libc-alpha at sourceware dot org>, meissner at suse dot de,lnussel at suse dot de
- Date: Mon, 2 Apr 2012 12:31:42 +0200
- Subject: Re: ~/.localtime ?
- References: <4F4F2DBD.7010206@suse.com> <201203291557.19019.aj@suse.com> <20120331025211.AB1FA2C0C5@topped-with-meat.com>
On Saturday, March 31, 2012 04:52:11 Roland McGrath wrote:
> I don't like the idea of that being built-in behavior, for mutltiple
> reasons. One is the extra syscall to attempt to open the missing file
> first before opening /etc/localtime. Another is the security concern.
> There are many security experts to weigh in, not just yours. And even
> supposed security experts can overlook things. (Admittedly, a third
> reason is just me being reactionary about new things we haven't ever
> needed since 1987 so why do we need them now?)
>
> For every security person I've come across, I think the notion of adding
> to the set of files--especially ones whose exact names vary and are
> affected by environment variables--that are opened by more or less
> every random program would be an immediate red flag to consider very
> carefully. Are we going to ignore the file under __libc_enable_secure?
> Are we going to add HOME to UNSECURE_ENVVARS? etc.
> Anyway, the fact that I can't accept your proposal doesn't mean we can't
> implement the functionality that you actually want.
Thanks for trying to help solve the problem.
> What seems entirely reasonable to me is to extend or change our
> implementation-defined behavior for values of TZ starting with :.
> (Currently we just ignore the :, so it might be either a zoneinfo file
> name or POSIX.1 TZ syntax.) If we don't care that much about
> compatibility with dubiously-useful existing uses of the syntax, then
> an obvious thing is to make it:
>
> TZ=:FILE[:FILE]...
>
> i.e., a search list of files to use, the first that's opened being
> taken. The list, rather than the individual file previously chosen,
> would be reevaluated from scratch at tzset time, in case a file earlier
> in the list didn't exist before and now does.
>
> Then a user's environment, presumably set by default in the desktop
> system or /etc/profile or whatnot, could contain:
>
> TZ=:$HOME/.localtime:/etc/localtime
>
> Of course, nothing today stops you from putting into /etc/profile:
>
> test -e $HOME/.localtime || ln -snf /etc/localtime $HOME/.localtime
> TZ=:$HOME/.localtime
The following code in tzset.c around line 425 optimizes too much for this
to work:
/* Check whether the value changed since the last run. */
if (old_tz != NULL && tz != NULL && strcmp (tz, old_tz) == 0)
/* No change, simply return. */
return;
If TZ is not set, then /etc/localtime is read and the application gets a
change of /etc/localtime. But if TZ is set like you propose then, tz and
old_tz have the same value and therefor no change of $HOME/.localtime is
noticed by the clock applet ;-(
The above check is fine for setting TZ=Europe/Berlin or even for defining
your own TZ rule - but it might optimize too much in case of
> But the search-list feature seems nicer (if not necessarily the exact
> syntax I used in my examples). It's already the case that TZ settings
> can cause a program to read any named file (i.e. "TZ=:/dev/rst0
> something-suid" might rewind the tape drive), so the security situation
> is unchanged by adding this feature.
There's a check for SUID applications in tzfile.c around line 135:
/* We must not allow to read an arbitrary file in a setuid
program. So we fail for any file which is not in the
directory hierachy starting at TZDIR
and which is not the system wide default TZDEFAULT. */
if (__libc_enable_secure
&& ((*file == '/'
&& memcmp (file, TZDEFAULT, sizeof TZDEFAULT)
&& memcmp (file, default_tzdir, sizeof (default_tzdir) - 1))
|| strstr (file, "../") != NULL))
/* This test is certainly a bit too restrictive but it should
catch all critical cases. */
So, there shouldn't be a problem with /dev/rst0 - but setuid applications
will not be able to access the HOME directory.
But root having a different time than a user might confuse people...
This whole concept needs some more investigation.
Roland, thanks for your comments,
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126