linux-kernel - Re: [Y2038] [RFC 02/15] vfs: Change all structures to support 64 bit time

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:	Fri, 15 Jan 2016 13:27:34 +1100
From:	Dave Chinner <david@...morbit.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	y2038@...ts.linaro.org, linux-fsdevel@...r.kernel.org,
	Deepa Dinamani <deepa.kernel@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [Y2038] [RFC 02/15] vfs: Change all structures to support 64 bit
 time

On Thu, Jan 14, 2016 at 11:54:36PM +0100, Arnd Bergmann wrote:
> On Thursday 14 January 2016 23:46:16 Arnd Bergmann wrote:
> > 
> > I'm not following the line of thought here. We have some users
> > that want ext4 to mount old file system images without long
> > inodes writable, because they don't care about the 2038 problem.
> > We also have other users that want to force the same file system
> > image to be read-only because they want to ensure that it does
> > not stop working correctly when the time overflow happens while
> > the fs is mounted.
> > 
> > If you don't want a compile-time option for it, how do you suggest
> > we decide which case we have?
> 
> In case that came across wrong, I'm assuming that the first
> user also wants all the system calls enabled that pass 32-bit
> time_t values, while the second one wants them all left out from
> the kernel to ensure that no user space program gets incorrect
> data.

system call API support is a completely different class of problem.
It's out of the scope of this patchset, and really I don't care what
you do with them.

The point I'm making is that we'll have to modify all the existing
filesystem code to supply a valid timestamp range to the VFS at
mount time for the range checking/clamping, similar to how we do the
granularity specification right now. That means we can do rejection
of non-y2038k compliant filesystems at runtime based on what the
filesystem tells the VFS it supports..  Set up the default to be
reject if rw, allow if ro, and provide a mount option to override ad
allow mounting rw.

Users can then make the decision when mounting their filesystems.
If they are system/automatically mounted filesystems and aren't
y2038k compliant, then the override option can be added to
/etc/fstab and we're all good. If the truly paranoid users want to
disallow the override and/or read only mount options, then add a
sysctl to control that.

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com