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  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, 26 May 2007 03:06:19 +0530
From:	Kalpak Shah <kalpak@...sterfs.com>
To:	Theodore Tso <tytso@....edu>
Cc:	linux-ext4 <linux-ext4@...r.kernel.org>,
	Andreas Dilger <adilger@...sterfs.com>
Subject: Re: [RFC][PATCH] Multiple mount protection

Hi Ted,

On Fri, 2007-05-25 at 10:39 -0400, Theodore Tso wrote:
> Hi Kalpak,
> 
> On Tue, May 22, 2007 at 01:22:32AM +0530, Kalpak Shah wrote:
> > It will also protect against running e2fsck on a mounted filesystem
> > by adding similar logic to ext2fs_open().
> 
> Your patch didn't add this logic to ext2fs_open(); it just reserved
> the space in the superblock.

Yeah the earlier patch for just reserving the fields. 

> 
> I don't mind reserving the space so we don't have to worry about
> conflicting superblock uses, but I'm still on the fence about actually
> adding this functionality (a) into e2fsprogs, and (b) into the ext4
> kernel code.  I guess it depends on how complicated/icky the
> implementation code is, I guess.

I am attaching the kernel and e2fsrogs patches so that you can suggest
any short-comings in the implementation. These patches are still a WIP.

>   The question as before is whether
> the complexity is worth it, given that someone who is actually going
> to be subject to accidentally mounting an ext3/4 filesystem on
> multiple systems needs to be using an HA system anyway.  So basically
> this is just to protect against (a) a bug/failure in the HA subsystem,
> and (b) the idiotic user that failed to realized he/she needed to set
> up an HA subsystem in the first place.  Granted, the universe is going
> to create idiots at a faster rate that we can deal with it, but that's
> why I'm still not 100% convinced the complexity is worth it.

Given the amount of damage that multiple mounts can cause to the
filesystem, it would be desirable to make doubly sure. Also the MMP
feature is quite uncomplicated and absolutely tunable.

Thanks for your views.

- Kalpak.
> 
> To be fair, if I was on a L3 support team having to deal with these
> idiots, I'd probably feel differently.  :-)
> 
> 							- Ted
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

View attachment "mmp.patch" of type "text/x-patch" (10099 bytes)

View attachment "e2fsprogs-mmp.patch" of type "text/x-patch" (24052 bytes)

Powered by blists - more mailing lists