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: <20160115224123.GT10456@dastard>
Date:	Sat, 16 Jan 2016 09:41:23 +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 Fri, Jan 15, 2016 at 06:01:36PM +0100, Arnd Bergmann wrote:
> On Friday 15 January 2016 13:27:34 Dave Chinner wrote:
> > 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.

Right, I was refering to the behaviour of a y2038k compliant kernel,
A current non-compliant kernel will have the default behaviour you
are suggesting.

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

Yup, that's exactly what I was implying.

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

Distros should not be forces to ship multiple kernels just to
provide all the different runtime compliance behaviours their users
require. Make the policy runtime enforcable, but select the default
behaviour and supported policies via compile time options.

Cheers,

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ