linux-kernel - Re: [RFC 0/6] vfs: Add timestamp range check support

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: <20161103234802.GK14023@dastard>
Date:   Fri, 4 Nov 2016 10:48:02 +1100
From:   Dave Chinner <david@...morbit.com>
To:     Theodore Ts'o <tytso@....edu>,
        Deepa Dinamani <deepa.kernel@...il.com>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        arnd@...db.de, tglx@...utronix.de, gregkh@...uxfoundation.org,
        akpm@...ux-foundation.org, viro@...iv.linux.org.uk,
        y2038@...ts.linaro.org, linux-afs@...ts.infradead.org,
        Andreas Dilger <adilger.kernel@...ger.ca>,
        linux-ext4@...r.kernel.org
Subject: Re: [RFC 0/6] vfs: Add timestamp range check support

On Thu, Nov 03, 2016 at 04:43:57PM -0400, Theodore Ts'o wrote:
> On Thu, Nov 03, 2016 at 09:48:27AM +1100, Dave Chinner wrote:
> > 
> > We're going to need regression tests for this to ensure that it
> > works properly and that we don't inadvertantly break it in future.
> > Can you write some xfstests that exercise this functionality and
> > validate that the mount behaviour, clamping and range limiting is
> > working as intended?
> 
> In order to have automated regression tests which are file system
> independent, we need a way to query what are the timestamps that a
> particular mounted file systme supports.

We don't need that - we simply code it directly into the test
infrastructure, like we've done for things like the maximum number
of ACLs a filesystem supports (common/attr::_acl_get_max()).

> The last option, which is admittedly ugly, would be to create an shell
> function which knows how to figure out the max_timestamp and
> min_timestamp by using the file system name and querying the
> superblock using dumpe2fs, xfs_db, etc.

Yup, precisely that. We shouldn't trust the kernel to tell us the
correct thing to enable the test that tells us that thing is working
correctly or not...

> I'd argue for the last option because once we do get a programmtic way
> to get the information via a system call such as fsinfo(2), we can
> convert xfstests to use it, where as if we add an ioctl to return this
> information, we'll have to support the ioctl forever.

We have to support kernels that won't ever have something like
fsinfo, so it has to be done the "ugly way".

Cheers,

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