Re: Feature bug with the new mount API: no way of doing read only bind mounts

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Thu, 2019-11-21 at 08:10 +0000, David Howells wrote:
> James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> 
> > I was looking to use the read only bind mount as a template for
> > reimplementing shiftfs when I discovered that you can't actually
> > create a read only bind mount with the new API.  The problem is
> > that fspick() will only reconfigure the underlying superblock,
> > which you don't want because you only want the bound subtree to
> > become read only and open_tree()/move_mount() doesn't give you any
> > facility to add or change options on the bind.
> 
> You'd use open_tree() with OPEN_TREE_CLONE and possibly AT_RECURSIVE
> rather than fspick().  fspick() is, as you observed, more for
> reconfiguring the superblock.

In the abstract, I think the concept of a configuration file descriptor
with the, open add parameters and execution to fd, and optionally
convert to representation or reconfigure in place is a very generic
one.  If we did agree to do that for bind mounts as well, I wouldn't
overload the existing logic, I'd lift it up to the generic level,
probably by hooking the execution parts, and make superblock and bind
two implementations of it.  It would basically be 3 system calls:
configopen, configparam and configconvert although obviously with more
appealing names.

The reason for thinking like this is I can see it having utility in
some of the more complex SCSI configuration operations we do today via
a bunch of mechanisms including configfs that could more compactly be
done by this file descriptor mechanism.

I'd also note that this plethora of system calls you have could then go
away: fspick itself would just become an open type to which the path
file descriptor would then be a required parameter, as would open_tree
and the missing mount_setattr would then just work.

James