linux-kernel - Re: [PATCH v11 21/48] ext4: Add richacl feature flag

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20151017231759.GV27164@dastard>
Date:	Sun, 18 Oct 2015 10:17:59 +1100
From:	Dave Chinner <david@...morbit.com>
To:	Austin S Hemmelgarn <ahferroin7@...il.com>
Cc:	Andreas Gruenbacher <agruenba@...hat.com>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Theodore Ts'o <tytso@....edu>,
	Andreas Dilger <adilger.kernel@...ger.ca>,
	"J. Bruce Fields" <bfields@...ldses.org>,
	Jeff Layton <jlayton@...chiereds.net>,
	Trond Myklebust <trond.myklebust@...marydata.com>,
	Anna Schumaker <anna.schumaker@...app.com>,
	linux-ext4 <linux-ext4@...r.kernel.org>, xfs@....sgi.com,
	LKML <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
	linux-cifs@...r.kernel.org, Linux API <linux-api@...r.kernel.org>,
	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
Subject: Re: [PATCH v11 21/48] ext4: Add richacl feature flag

On Fri, Oct 16, 2015 at 02:27:57PM -0400, Austin S Hemmelgarn wrote:
> On 2015-10-16 13:41, Andreas Gruenbacher wrote:
> >On Fri, Oct 16, 2015 at 7:31 PM, Austin S Hemmelgarn
> ><ahferroin7@...il.com> wrote:
> >>I would like to re-iterate, on both XFS and ext4, I _really_ think this
> >>should be a ro_compat flag, and not an incompat one.  If a person has the
> >>ability to mount the FS (even if it's a read-only mount), then they by
> >>definition have read access to the file or partition that the filesystem is
> >>contained in, which means that any ACL's stored on the filesystem are
> >>functionally irrelevant,
> >
> >It is unfortunately not safe to make such a file system accessible to
> >other users, so the feature is not strictly read-only compatible.
> If it's not safe WRT data integrity, then the design needs to be
> reworked, as that directly implies that isn't safe for even every
> day usage on a writable filesystem.

This is exactly what we have *incompat feature flags for*: to
protect old code that doesn't know about potentially dangerous new
on-disk formats from trying to parse those formats and causing
unpredictable bad things from happening.

Austin, your arguments hold no weight because they are no different
to the considerations for any new on-disk feature: the user needs to
have both kernel and userspace support to recover filesystems that
go bad. If you are using a brand new fs/kernel feature, then it is
expected that you know that your DR processes take this into
account.

This is also why we XFS devs wait at least a year after new on-disk
features are merged into XFS before we consider turning them on by
default. i.e.  to give distros and recovery utilities time to pick
up kernels and userspace pacakges that support the new feature
before the average user will encounter it....

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/