linux-kernel - Locating tz=UTC problem with vfat filesystem

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>] [day] [month] [year] [list]

Message-ID: <87v9vrn3zo.fsf@fencepost.gnu.org>
Date:   Wed, 24 Jul 2019 12:03:55 +0200
From:   David Kastrup <dak@....org>
To:     linux-kernel@...r.kernel.org
Subject: Locating tz=UTC problem with vfat filesystem

Hi,

I'm plagued with Ubuntu (currently eoan but was the same previously)
with regard to vfat filesystem timezone.

uname -a gives

Linux lola 5.2.0-8-lowlatency #9-Ubuntu SMP PREEMPT Mon Jul 8 13:49:06 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

The documentation states that mount option tz=UTC is required for having
timestamps in fat filesystems interpreted relative to UTC.  However, no
such option is listed in the mount flags and nevertheless timestamps on
my (fat32) memory sticks are interpreted as being relative to UTC.  This
is with several card readers as well as my (timezone agnostic) Sony
DSC-R1 camera as USB reader.  There does not seem to be a corresponding
option for switching tz=UTC off explicitly and I think if it were
switched on explicitly by some code, it should get listed in the mount
flags.

The mount subsystem is some sort of udisks2 based on udev: I don't
really manage to find myself through the documentation of that.  Note
that the exfat file system is supposed to have some sort of timezone
support but that is not the case for other fat filesystems.

So I think something must have gone awry somewhere and due to the lack
of visible mount options, I do suspect this to be kernel involved but
may well be wrong.

Does anybody have a clue how I can get behind this and figure out where
the source of the problem (code and/or documentation) lies and how to
move forward with regard to getting it fixed?  There would be the
workaround of setting the camera clock to UTC, but since this behavior
is clearly completely different than the documented behavior, that seems
like skirting the issue which seems to be in want of fixing.

Or is there something one can set on the filesystem media itself to mark
it as being localtime relative?  That would likely be the most reliable
way since it would allow one to treat different media differently,
depending on whether their usual hosting device has a notion of
timezones and/or UTC.

Thanks!

-- 
David Kastrup