Re: exact semantics of union mounts (and TRYEMULROOT)

[David Holland <dholland-tech%netbsd.org@localhost>]

On Mon, Jul 10, 2017 at 02:07:35PM -0400, Mouse wrote:
 > > So I think these should behave as follows:
 > 
 > Whiteouts complicate this.  I can't recall whether whiteouts are -o
 > union or -t union, but they can occur; even if they are strictly -t
 > union, a plain filesystem that got a whiteout created by being part of
 > -t union could be remounted as part of -o union.

Blah, I'd completely blocked out the existence of whiteouts. And yes,
it matters, unless we want to declare that whiteouts don't affect
union mounts.

 > Also, the 5.2 mount(8) manpage says
 > 
 >              union       Causes the namespace at the mount point to appear as
 >                          the union of the mounted file system root and the
 >                          existing directory.  Lookups will be done in the
 >                          mounted file system first.  If those operations fail
 >                          due to a non-existent file the underlying directory
 >                          is then accessed.  All creates are done in the
 >                          mounted file system, except for the fdesc file sys-
 >                          tem.
 > 
 > It's not clear whether what you are trying to do is to turn mount -o
 > union into something closer to mount -t union, but, if not, it sounds
 > to me as though the above preempts most of your questions.

No, it doesn't. Union mounts were invented by Plan 9 and the Plan 9
behavior is the normative reference. Vague and ambiguous statements in
our man pages aren't particularly helpful.

(also whatever special-case handling fdesc might have had at one point
doesn't currently exist)

 > > For nonexclusive create, we should do the same, and if we run out of
 > > layers start at the top again and, knowing that the name doesn't
 > > exist, continue like an exclusive create.
 > 
 > > For an exclusive create, [...]
 > 
 > Possibly.  How is O_CREAT|O_EXCL supposed to interact with whiteouts?

The point of a whiteout with onionfs is to be able to use a read-write
upper layer to remove files from a read-only lower layer. So from at
or above the whiteout it should be the same as there being no such
file, and one should not look under a whiteout at all.

 > > Once we've ascertained that the name doesn't exist, we use the
 > > topmost read-write layer; that is, start at the top and descend
 > > skipping layers that are tagged readonly.  (But: does this strictly
 > > mean readonly as in EROFS, or do we skip layers that are chmod -w for
 > > the current user?)
 > 
 > Personally, I think it should be EROFS.  I can see use cases for
 > covering a writable directory with a readonly one.  If there really is
 > disagreement, I guess it needs to be a mount option.

I agree, and I don't think there's particular disagreement, I was just
thinking out loud.

 > > For remove, I think the correct thing to do is to descend until we
 > > find the topmost layer where the target name exists, if any, and then
 > > operate at that layer.
 > 
 > What about creating whiteouts?

I think that should function as a create :-)

 > > And for rename, I think the correct thing is to make like remove on
 > > the first (from-dir) argument, then find whatever layer in the second
 > > (to-dir) argument is the same volume, regardless of stack order.
 > > This can result in moving a file under another file, but that's what
 > > Plan 9 does and I guess it's ok.
 > 
 > Maybe.  For what value of "ok"?  It seems to me that if rename("x","y")
 > succeeds, "y" should then refer to the file "x" used to refer to, which
 > that violates.

The alternative is to check for the destination name existing on each
layer of the destination directory that's above the volume of the
source directory, and if so fail with EXDEV.

However, I think we should follow Plan 9 unless there's a good reason
not to. (Plan 9 doesn't have cross-directory rename but the behavior
cited is what happens when renaming within one directory.)

-- 
David A. Holland
dholland%netbsd.org@localhost