linux-kernel - Re: [PATCH v10 09/14] exfat: add misc operations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK8P3a1iYPA9MrXORiWmy1vQGoazwHs7OfPdoHLZLJDWqu9jqA@mail.gmail.com>
Date:   Wed, 15 Jan 2020 16:52:12 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Pali Rohár <pali.rohar@...il.com>
Cc:     Namjae Jeon <linkinjeon@...il.com>,
        Namjae Jeon <namjae.jeon@...sung.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Linux FS-devel Mailing List <linux-fsdevel@...r.kernel.org>,
        gregkh <gregkh@...uxfoundation.org>,
        Valdis Kletnieks <valdis.kletnieks@...edu>,
        Christoph Hellwig <hch@....de>, sj1557.seo@...sung.com
Subject: Re: [PATCH v10 09/14] exfat: add misc operations

On Wed, Jan 15, 2020 at 4:39 PM Pali Rohár <pali.rohar@...il.com> wrote:
> On Wednesday 15 January 2020 16:03:12 Arnd Bergmann wrote:
> > The vdso and kernel/time/ code are for maintaining the timezone through
> > settimeofday()/gettimeofday(), and the drivers should probably all be changed
> > to use UTC. The file systems (affs, fat, hfs, hpfs and udf) do this for
> > compatibility with other operating systems that store the metadata in
> > localtime.
>
> Ok. But situation for exFAT is quite different. exFAT timestamp
> structure contains also timezone information. Other filesystems do not
> store timezone into their metadata (IIRC udf is exception and also
> stores timezone). So question is in which timezone we should store to
> exFAT timestamps. This is not for compatibility with legacy systems, but
> because of fact that filesystem supports feature which is not common for
> other filesystems.
>
> Also, to make it more complicated exFAT supports storing timestamps also
> in "unspecified" (local user) timezone, which matches other linux
> filesystems.
>
> So for storing timestamp we have options:
>
> * Store them without timezone
> * Store them in sys_tz timezone
> * Store them in timezone specified in mount option
> * Store them in UTC timezone
>
> And when reading timestamp from exFAT we need to handle both:
>
> * Timestamps without timezone
> * Timestamps with timezone

Right.

> So what is the best way to handle timezone/timestamps?
>
> For me it looks sane:
>
> When storing use: mount option timezone. When not available then use
> sys_tz. And when sys_tz is not set (it is possible?), do not specify
> timezone at all. Maybe there should be a mount option which says that
> timestamps on exfat are stored without timezone.

I would argue we should always store files in UTC, which seems to be
the most consistent with other file systems, and can be understood
by any other implementation that understands the timezone information
on disk  or that expects UTC.

> When reading timestamp with timezone: Convert timestamp to timezone
> specified in mount option (or fallback to sys_tz or fallback to UTC).

Here I would just convert to UTC, which is what we store in the
in-memory struct inode anyway.

> And when reading timestamp without timezone: Pass it as is without
> conversion, ignoring all timezone mount options and sys_tz.
>
> Arnd, what do you think about it?

The last case (reading timestamp without timezone) is the only
one that I think we have to decide on: when reading an inode from
disk into memory, we have to convert it into UTC in some form.

This is what I think the timezone mount option should be used
for: if we don't know what the timezone was for the on-disk
timestamp, use the one provided by the user. However, if none
was specified, it should be either sys_tz or UTC (i.e. no
conversion). I would prefer the use of UTC here given the
problems with sys_tz, but sys_tz would be more consistent
with how fs/fat works.

    Arnd