linux-kernel - Re: [PATCH 0/5] hybrid union filesystem prototype

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: <20100901015616.GD5759@shell>
Date:	Tue, 31 Aug 2010 21:56:16 -0400
From:	Valerie Aurora <vaurora@...hat.com>
To:	Trond Myklebust <Trond.Myklebust@...app.com>
Cc:	Miklos Szeredi <miklos@...redi.hu>,
	"J. Bruce Fields" <bfields@...ldses.org>,
	Neil Brown <neilb@...e.de>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, viro@...iv.linux.org.uk,
	jblunck@...e.de, hch@...radead.org
Subject: Re: [PATCH 0/5] hybrid union filesystem prototype

On Tue, Aug 31, 2010 at 04:19:47PM -0400, Trond Myklebust wrote:
> On Tue, 2010-08-31 at 15:18 -0400, Valerie Aurora wrote:
> > On Mon, Aug 30, 2010 at 02:20:47PM +0200, Miklos Szeredi wrote:
> > > On Mon, 30 Aug 2010, Neil Brown wrote:
> > > 
> > > > Val has been following that approach and asking if it is possible to make an
> > > > NFS filesystem really-truly read-only. i.e. no changes.
> > > > I don't believe it is.
> > > 
> > > Perhaps it doesn't matter.  The nasty cases can be prevented by just
> > > disallowing local modification.  For the rest NFS will return ESTALE:
> > > "though luck, why didn't you follow the rules?"
> > 
> > I agree: Ask the server to keep it read-only, but also detect if it
> > lied to prevent kernel bugs on the client.
> > 
> > Is detecting ESTALE and failing the mount sufficient to detect all
> > cases of a cached directory being altered?
> 
> No. Files can be altered without being unlinked.

Argh.  Do generation numbers and/or mtime help us here?

> >   I keep trying to trap an
> > NFS developer and beat the answer out of him but they usually get hung
> > up on the impossibility of 100% enforcement of the read-only server
> > option. (Agreed, impossible, just give the sysadmin a mount option so
> > that it doesn't happen accidentally.)
> 
> Remind me again why mounting the filesystem '-oro' on the server (and
> possibly exporting it 'ro') isn't an option?

The "hard read only" export option is to, at minimum, make it
difficult to *accidentally* remount the file system on the server as
read-write while it is exported as a union lower layer.

True, the NFS server can mount the file system "-o ro" - and then any
random other mount(8) on the server can come along and "-o
remount,rw".  So if we have an NFS server option that uses the new
hard read-only feature, this at least makes the admin go change the
NFS mount options or unexport it before writing to the exported union
lower layer and hosing all the union mount clients.

It's the difference between:

# mount -o remount,rw /exports/union_mount_root
 [thousands of union mounted clients hang]

And:

# mount -o remount,rw /exports/union_mount_root
mount: /exports/union_mount_root is hard read-only
# emacs /etc/exports
  [edit out union/hard readonly option]
# exportfs -r
 [thousands of union mounted clients hang]

But heck, system administration is hard, what's a little more rope?
Here, hold this gun while I position your foot...

-VAL
--
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/