linux-kernel - Re: Revoking filesystems [was Re: Sysfs attributes racing with unregistration]

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: <20120105192822.GD26382@thunk.org>
Date:	Thu, 5 Jan 2012 14:28:22 -0500
From:	Ted Ts'o <tytso@....edu>
To:	Tejun Heo <tj@...nel.org>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Kay Sievers <kay.sievers@...y.org>
Subject: Re: Revoking filesystems [was Re: Sysfs attributes racing with
 unregistration]

On Thu, Jan 05, 2012 at 10:36:02AM -0800, Tejun Heo wrote:
> Hello, Ted.
> 
> On Thu, Jan 05, 2012 at 01:27:52PM -0500, Ted Ts'o wrote:
> > So it's really more of a filesystem force-umount method.  I could
> > imagine that this could also be used to extend the functionality of
> > umount(2) so that the MNT_FORCE flag could be used with non-NFS file
> > systems as well as NFS file systems.
> 
> I think these are two separate mechanisms.  Filesystems need to be
> able to handle IO errors no matter what and underlying device going
> away is the same situation.  There's no reason to mix that with force
> unmount.  That's a separate feature and whether to force unmount
> filesystem on device removal or permanent failure is a policy decision
> which belongs to userland - ie. if such behavior is desired, it should
> be implemented via udev/udisk instead of hard coded logic in kernel.

I think it's needless complexity to loop this into userspace.  If the
block device is gone, it's *gone*.  What else could userspace do with
this information that block device has disappeared?  Right now, once
gone, it's never coming back.  Even if the luser plugs the USB device
back in, it's going to be coming back as a new block device node.

So we might as well automatically forcibly unmount the file system at
this point.  I can imagine sending an optional notification that such
a thing has happened, perhaps via a netlink socket, but why not have
the kernel do the right thing automatically?

> I don't know enough to decide whether such forced unmount is a useful
> feature tho.  It can be neat for development but is there any real
> necessity for the feature?

Well, if you want to complicate matters by having this go via a
notification up to userspace, and then have the userspace thoughtfully
consider (after looking up all sorts of complex rules stored in XML
files whose schema is documented nowhere but in the source code) that
the file system should go away because the block device has gone away,
the userspace code will then have to send a forced unmount.

The other use case would be a system administrator who doesn't want to
figure out which random shell is still cd'ed into a directory of a
file system he/she wants to unmount, he can still force the umount.
(Other Unix systems have had this feature in the past, and the result
is the same as what happens if you are cd'ed into a directory which is
later rmdir'ed.)  It's an ungraceful way of running things, but
sometimes it's the easist way to go.

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