linux-ext4 - Re: [PATCH v5 2/5] vfs: Add checks for filesystem timestamp limits

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]

Date:   Sat, 8 Apr 2017 19:58:39 -0700
From:   Deepa Dinamani <deepa.kernel@...il.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Al Viro <viro@...iv.linux.org.uk>, "Theodore Ts'o" <tytso@....edu>,
        "adilger.kernel@...ger.ca" <adilger.kernel@...ger.ca>,
        "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>,
        y2038 Mailman List <y2038@...ts.linaro.org>
Subject: Re: [PATCH v5 2/5] vfs: Add checks for filesystem timestamp limits

>> Allow read only mounts for filesystems that do not
>> have maximum timestamps beyond the y2038 expiry
>> timestamp.
>
> This option seems arbitrary and pointless.
>
> Nobody sane should ever enable it except for testing, but for testing
> it would be much better to simply specify what the limit should be:
> 2038 is not magical for all filesystems, because the base may be
> different.

Yes, the way the patch is right now, it is meant only for testing
y2038 readiness.
The feature is meant for system wide tests and not individual filesystem tests.

The original idea was to disallow writes on all filesystem mounts that
were not able to update times at the time of mount, meaning max time
supported by the filesystem should be greater than current system
time. But, then we end up with the problem of what to do about mounts
whose max time exceeds current time after mount. This can be handled
by some logic while updating inode times. But, maybe this level of
complexity is not required and we could just stick to the former use
case. And, just print a warning in the latter case. This is what
pushes the feature to be something more than y2038 readiness.

> And honestly, for testing, it would be much better to just make it a
> mount option rather than some crazy system-wide one.

The patch allows the y2038 number to be changed at compile time. I can
extend the sysctl and boot option to allow changing of this limit also
if that is preferred.

We also proposed the mount option route in the RFC. But, we received
no preferences/ comments. We proceeded with the sysctl option because
this allows us to extend this feature into disallowing writes on non
updatable time filesystems.

I could change this to providing a mount option instead if you think
that is better.

-Deepa