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]

Message-ID: <7254587.VgG2py0ZUI@wuerfel>
Date:	Fri, 15 Jan 2016 18:01:36 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Dave Chinner <david@...morbit.com>
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 Friday 15 January 2016 13:27:34 Dave Chinner wrote:
> 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.

Sure, I was just providing some background about why we want a
compile-time option in general.

> 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.

We can't really default to "reject if rw", because that would break
all systems using ext3 or xfs, unless users modify their fstab
or set the flag that makes the partition y2038 compliant.

The compile-time option that I'm thinking of would change the default
beween "always allow" and "reject if rw", based on whether the
system cares about this issue or not. Almost everyone today won't
care about it at all and would be rather annoyed by being unable
to mount their rootfs, but some people care about the behavior
a lot.

Having a global sysctl or mount option as an override would be good,
maybe both if that isn't over-engineering the problem when we already
have a compile-time option. 

	Arnd