Re: exact semantics of union mounts (and TRYEMULROOT)

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

On Tue, Jul 11, 2017 at 02:25:16AM +0700, Robert Elz wrote:
 >   | Union mounts are complicated in this regard because when the directory
 >   | involved is a union mount point, some layer of the union mount needs
 >   | to be chosen to invoke the filesystem-level operation;
 > 
 > I don't think so, directory ops all happen at the upper level (or nowhere).

I don't think that's what Plan 9 does but I'm willing to be shown I'm
wrong. That would be quite a bit simpler.

(it is also not what we currently do, not that what we currently do is
especially significant)

In Plan 9 the layer creations happen in is chosen by a mount flag, and
isn't necessarily the top layer. We don't have that flag (but could
add it, as I noted) - my original mail was using "not readonly" as a
proxy for it.

I don't think deletes are restricted to that layer though.

 >   | Directory operations can be divided into five categories:
 >   |  - lookup (ordinary directory traversal, operations like stat, open
 >   |       without O_CREATE, etc.)
 >   |  - nonexclusive create (open without O_CREATE)
 > 
 > You mean without O_EXCL,

er right

 >   |  - exclusive create (mkdir, symlink, open with O_CREATE|O_EXCL, etc.)
 >   |  - remove (rmdir, unlink)
 >   |  - rename
 > 
 > Forget rename(), the relevant operation is link() - rename is just
 > link(),unlink() with idempotent semantics.

Same set of questions arises.

 >   | For lookup,
 > 
 > Agreed, no question.   And to answer mouse, if there's a whiteout found,
 > the search terminates, and the file was not found.
 > 
 >   | For nonexclusive create, we should do the same, and if we run out of
 >   | layers start at the top again
 > 
 > No, if the file does not exist, it is created, in the top level, there
 > is no "start again"

How do you propose to get back to the top level without starting at
the top again?

 >   | Various security
 >   | properties depend on exclusive create actually being exclusive, and I
 >   | don't think having union mounts weaken this is healthy.
 > 
 > Of course.
 > 
 >   | So I think we need to test all layers before creating anything.
 > 
 > Of course.
 > 
 >   | (It also means we need to lock all layers,
 > 
 > The top layer needs to be locked, and remain that way, I expect (though
 > we just have a normal race if it is unlocked, then locked again later,
 > only effect would be, I think, that the top directory would need to be
 > checked again in case the file appeared in the meantime.)   That is, anyone
 > creating the same file name will put it in the upper layer, and it is
 > just a question of who gets there first, which is something we do not need
 > to answer, just make sure there is only one winner.   If someone at the
 > same time is creating a file in the alternative name for the under layer
 > then "so what", that's not a problem.

Ok, so we don't need to lock the layers under the one where creation
happens, but that doesn't help much.

 >   | Once we've ascertained that the name doesn't exist, we use the topmost
 >   | read-write layer;
 > 
 > Huh?  Where does that come from?   You use the upper layer.  If for any
 > reason the file cannot be created there, the operation fails.   No second
 > chances.

See above.

 >   | 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,
 > 
 > We look see if the file exists, yes, if not there is nothing to do (error.)
 > 
 >   | and then operate at that layer.
 > 
 > No, all changes in the top layer, the file is "removed" by creating
 > a whiteout, which will then cause any lookup to fail.

Wrong... Plan 9 doesn't have whiteouts.

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