kern/46626: EROFS enforcement in namei breaks union mounts

[dholland%NetBSD.org@localhost]

>Number:         46626
>Category:       kern
>Synopsis:       EROFS enforcement in namei breaks union mounts
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Jun 24 23:15:00 +0000 2012
>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.