linux-kernel - Re: [PATCH v6 3/4] vfs: Add timestamp

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: <CA+55aFy1Lue+txzoCDJF9XR2bCvWz0W5s0tB+XXQkyf2KaxiOg@mail.gmail.com>
Date:   Wed, 24 Jan 2018 10:00:45 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Deepa Dinamani <deepa.kernel@...il.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        "Theodore Ts'o" <tytso@....edu>,
        Andreas Dilger <adilger.kernel@...ger.ca>,
        linux-ext4@...r.kernel.org,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        y2038 Mailman List <y2038@...ts.linaro.org>
Subject: Re: [PATCH v6 3/4] vfs: Add timestamp_truncate() api

On Wed, Jan 24, 2018 at 3:56 AM, Arnd Bergmann <arnd@...db.de> wrote:
> On Tue, Jan 23, 2018 at 5:25 PM, Deepa Dinamani <deepa.kernel@...il.com> wrote:
>>
>> I checked POSIX again. There is no mention of tv_nsec being positive
>> always for utimes.
>> And, the long term plan is to replace all the callers of
>> timespec_trunc() to use this new api instead for filesystems.
>> So this will need to be fixed. I will fix this and post an update.
>
> I found this on
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/utimes.html
>
> ERRORS
> These functions shall fail if:
> ...
> [EINVAL]
>  Either of the times argument structures specified a tv_nsec value that was
>  neither UTIME_NOW nor UTIME_OMIT, and was a value less than zero or
>  greater than or equal to 1000 million.

The thing is, we shouldn't check the standards, we should check what
we actually _do_.

And what we actually _do_ is to have a tv_nsec that is of type "long",
and while we do have a

  timespec64_valid(const struct timespec64 *ts)

and fs/utimes.c has a 'nsec_valid()' that apparently the utimes*
family of system calls all do end up using, I'm more worried about
something where we don't.

Because I'm almost certain that we've had cases where we just
normalize things after-the-fact.

This all likely isn't a big deal, but it does end up worrying me if we
then _depend_ on that granularity thing actually giving the proper
granularity even for odd inputs. If they can happen.

Maybe we don't care?

                 Linus