NetBSD Problem Report #46626

From dholland@netbsd.org  Sun Jun 24 23:14:58 2012
Return-Path: <dholland@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	by www.NetBSD.org (Postfix) with ESMTP id D27A763B85F
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 24 Jun 2012 23:14:57 +0000 (UTC)
Message-Id: <20120624231457.BB9F214A475@mail.netbsd.org>
Date: Sun, 24 Jun 2012 23:14:57 +0000 (UTC)
From: dholland@NetBSD.org
Reply-To: dholland@NetBSD.org
To: gnats-bugs@gnats.NetBSD.org
Subject: EROFS enforcement in namei breaks union mounts
X-Send-Pr-Version: 3.95

>Number:         46626
>Category:       kern
>Synopsis:       EROFS enforcement in namei breaks union mounts
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    dholland
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Jun 24 23:15:00 +0000 2012
>Last-Modified:  Tue Apr 10 09:00:00 +0000 2018
>Originator:     David A. Holland
>Release:        NetBSD 6.99.8 (20120624)
>Organization:
>Environment:
n/a
>Description:

Currently if you do a union mount (note for passersby: not unionfs) of
a read-write volume over a read-only volume, you get the following
annoying behavior:

	 % touch /dir/file
	 % rm /dir/file
	 % rm /dir/nonexistent
	 rm: /dir/nonexistent: Read-only file system
	 % 

Producing EROFS instead of ENOENT breaks some reasonable uses of union
mounts to provide a read-write directory overtop a read-only one.

If you mount in the other order, a read-only volume over a read-write
volume, then everything fails with EROFS. Admittedly this is not
necessarily a sensible thing to do. (But that's debatable.)

As I understand the way union mounts are supposed to work based on
Plan 9, for any operation, the layer in a union stack where the named
target exists should be selected to perform the operation. If the
named target does not exist, the top layer should be used. Having a
read-only upper layer arbitrarily intercept and deny all write
operations breaks these semantics.

(There's another wrinkle with rename, which is that if the to-file
doesn't exist, the layer of the from-file should be selected.
Otherwise, most rename operations will give EXDEV. This is not easy to
arrange, but it's a different problem.)

>How-To-Repeat:

>Fix:

Nontrivial. Reporting ENOENT in favor of EROFS when both apply should
fix the symptoms; however, arranging this is problematic. Currently
EROFS is enforced by namei before even checking if the target object
exists. Changing this requires either some ugly backing and filling in
namei (to do an extra lookup but without DELETE or whatever set),
which is not desirable, or shifting responsibility for EROFS
enforcement for directory ops to the file systems. This in turn
requires changing all the file systems, and, realistically, setting up
some kind of way to crosscheck that they actually do it properly.

>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: kern-bug-people->dholland
Responsible-Changed-By: dholland@NetBSD.org
Responsible-Changed-When: Sun, 24 Jun 2012 23:30:18 +0000
Responsible-Changed-Why:
namei


From: David Laight <david@l8s.co.uk>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/46626: EROFS enforcement in namei breaks union mounts
Date: Mon, 25 Jun 2012 07:55:19 +0100

 On Sun, Jun 24, 2012 at 11:15:00PM +0000, dholland@NetBSD.org wrote:
 > 
 > As I understand the way union mounts are supposed to work based on
 > Plan 9, for any operation, the layer in a union stack where the named
 > target exists should be selected to perform the operation. If the
 > named target does not exist, the top layer should be used. Having a
 > read-only upper layer arbitrarily intercept and deny all write
 > operations breaks these semantics.

 Letting a rename move files between layers does seem a little wrong!

 > (There's another wrinkle with rename, which is that if the to-file
 > doesn't exist, the layer of the from-file should be selected.
 > Otherwise, most rename operations will give EXDEV. This is not easy to
 > arrange, but it's a different problem.)

 I think the layer of the from-file should always be selected.
 This might mean you can move a file so that it is hidden! but
 you really don't want to move a file from a low-layer into a
 higher layer just because the file exists in the higher layer.

 Does the NetBSD code auto-created (and auto-delete) directories
 in the top layer?

 Somewhere I've probably got the sources for a 32-layer union
 mount filesystem (for SYSV) - which I fixed somewhat!
 Unless a specific layer was specified (append "\\n" to the name)
 all creates were done in layer 0, everything else just did a
 scan through the directories then 'handed off' the request to
 the located vnode.
 (Directory reads are hard, IIRC I left them O(N^2)).
 It was a shame that the kernel exec code didn't allow for VOP_OPEN()
 changing the vnode - otherwise the whole fs would only have had
 to process VOP_LOOKUP() and directory requests!

 	David

 -- 
 David Laight: david@l8s.co.uk

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/46626: EROFS enforcement in namei breaks union mounts
Date: Wed, 27 Jun 2012 04:20:00 +0000

 On Mon, Jun 25, 2012 at 07:05:04AM +0000, David Laight wrote:
  >  Letting a rename move files between layers does seem a little wrong!

 It can't. If the from and to sides of the rename select different
 layers, the result will be EXDEV. If this is not handled
 intelligently, almost all attempts to rename at a union mount will
 fail.

  >  > (There's another wrinkle with rename, which is that if the to-file
  >  > doesn't exist, the layer of the from-file should be selected.
  >  > Otherwise, most rename operations will give EXDEV. This is not easy to
  >  > arrange, but it's a different problem.)
  >  
  >  I think the layer of the from-file should always be selected.
  >  This might mean you can move a file so that it is hidden! but
  >  you really don't want to move a file from a low-layer into a
  >  higher layer just because the file exists in the higher layer.

 Again, you can't.

 But, how do you select the layer of the from-file for the to-file? It
 might not be the same directory and thus not part of the same union
 stack; also by the time rename sees it the union mount has already
 been processed.

 (In Plan 9 there are no cross-directory renames so it's a lot
 simpler.)

  >  Does the NetBSD code auto-created (and auto-delete) directories
  >  in the top layer?

 We aren't talking about onionfs here.

 -- 
 David A. Holland
 dholland@netbsd.org

From: coypu@sdf.org
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/46626: EROFS enforcement in namei breaks union mounts
Date: Sun, 26 Mar 2017 20:20:30 +0000

  I don't see the same error now, unless I am reproducing badly
  # mount -t null -o ro /tmp0 /tmp1
  # mount -t union /tmp2 /tmp1
  # touch /tmp1/File
  # rm /tmp1/File
  # rm /tmp1/nonexistent
  rm: /tmp1/nonexistent: No such file or directory

  Did you or someone else fix it?

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/46626: EROFS enforcement in namei breaks union mounts
Date: Tue, 10 Apr 2018 08:59:55 +0000

 On Sun, Mar 26, 2017 at 08:25:01PM +0000, coypu@sdf.org wrote:
  > The following reply was made to PR kern/46626; it has been noted by GNATS.
  > 
  > From: coypu@sdf.org
  > To: gnats-bugs@netbsd.org
  > Cc: 
  > Subject: Re: kern/46626: EROFS enforcement in namei breaks union mounts
  > Date: Sun, 26 Mar 2017 20:20:30 +0000
  > 
  >   I don't see the same error now, unless I am reproducing badly
  >   # mount -t null -o ro /tmp0 /tmp1
  >   # mount -t union /tmp2 /tmp1

 try with -o union (union mount, not unionfs)

  >   # touch /tmp1/File
  >   # rm /tmp1/File
  >   # rm /tmp1/nonexistent
  >   rm: /tmp1/nonexistent: No such file or directory
  >  
  >   Did you or someone else fix it?

 Nope.

 -- 
 David A. Holland
 dholland@netbsd.org

>Unformatted:

Home	PR Database Search