linux-kernel - Re: [PATCH 21/22] honor r/w changes at do

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]

Date:	Sat, 10 Feb 2007 00:29:40 +0000
From:	Anton Altaparmakov <aia21@....ac.uk>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Dave Hansen <hansendc@...ibm.com>, linux-kernel@...r.kernel.org,
	hch@...radead.org
Subject: Re: [PATCH 21/22] honor r/w changes at do_remount() time

On 9 Feb 2007, at 23:22, Andrew Morton wrote:
> On Fri, 09 Feb 2007 14:53:44 -0800
> Dave Hansen <hansendc@...ibm.com> wrote:
>
>> This is the core of the read-only bind mount patch set.
>
> Who wants read-only bind mounts, and for what reason?

On our local mirror server (mirrors just under 3TiB worth of stuff)  
we hold all data on r/w mounted storage in a private location in the  
file tree.  (Note the server runs Solaris 10 not Linux or the  
following would not be possible at present...)

We then bind mount (i.e. loopback mount on Solaris) various  
directories from inside the private paths to various other locations  
so for example we create /export/ftp/pub/* where "*" are directories  
we want to export via FTP and we do all of those as read-only bind  
mounts.  This gives us that little bit of extra confidence that no- 
one from the outside can cause any writes to happen to our mirrored  
data.  We do similar for NFS by creating lots of read-only bind  
mounts in /* that again point into the private locations.

It would be nice if the Linux box that we have that is a copy/backup  
of the Solaris box could do the same rather than have all the bind  
mounts be read-write because we need the storage in the private  
locations to be writable.

Best regards,

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