[PATCH 2/2] mount: -T OTHERTAB support

[Isaac Dunham]

On Sun, Mar 15, 2015 at 09:08:19PM +0100, Harald Becker wrote:
> On 15.03.2015 06:01, Isaac Dunham wrote:
> >>the fstab approach has one big cave-eat, which got me awy from that idea: he
> >>format of fstab does not allow to specify the owner, group and permissions
> >>of newly created mount points, but if you like / need to do some kind of
> >
> >Do you mean as in the permissions of the root of the mount:
> >
> >mount -o uid=xxxx,gid=xxxx,mode=0700
> 
> This may collide with setting the default uid / gid for mounted file
> systems, when those file systems do not use the usual Unix owner / group
> semantics.
> 
> Otherwise changing the owner / group would mean to overwrite the permission
> settings of the mounted file systems root directory, but still this can be
> of interest for virtual file systems.
> 
> 
> >or as in the permissions of the mountpoint itself, as entered in the
> >filesystem where it's found:
> >
> >mount -o x-mount.mkdir=0700
> 
> And here you are trying to add a very crazy and complicated syntax, for
> something required for several mount points.
> 

Just to clarify: this is NOT a feature I came up with.
I found it documented in the util-linux mount manpage:

       x-*    All  options  prefixed  with "x-" are interpreted as comments or
              userspace application-specific options.  These options  are  not
              stored  in  the  mtab file, nor sent to the mount.<type> helpers
              nor the mount(2) system call.  The suggested format  is  x-<app-
              name>.<option> (e.g. x-systemd.automount).

       x-mount.mkdir[=mode]
              Allow  to  make  a  target directory (mountpoint).  The optional
              argument mode specifies the  filesystem  access  mode  used  for
              mkdir(2)  in  octal  notation.   The default mode is 0755.  This
              functionality is supported only for root users.


My own idea was to make mount recognize "-d" as a signal that it should
create the mountpoint if needed.
 
> >which is always root:root since it is disallowed for non-root users, but
> >does *not* affect the permissions or ownership of the filesystem that is
> >mounted there.
> 
> ... and here you fail! Not everybody agree with the practice to have all
> "unused" mount points laying around with root:root 0755. It is just a
> visible indication for usage, or call it a reminder for novices (of no extra
> cost, except setting it up).

x-mount.mkdir does not create a mountpoint unless it is about to mount it.
And the -d flag I'd been thinking of would be similar.

In fact, given that we're talking about setting up submounts under
various kernel filesystems, these will be unmounted only in the following
cases:

-for a brief moment between mkdir() and mount(), while initscripts are
setting up the kernel mounts
-for a short period during shutdown, while the shutdown scripts are
unmounting everything
-and if the sysadmin does a non-recursive bind mount (such as if you
configure chroots by bind mounting /dev without using rbind) or manually
unmounts a kernel filesystem.

Given that only by a deliberate action of the sysadmin will such a mount
point be visible to users, is it unreasonable to expect that a sysadmin
who wants to change the owner/group could add a command to adjust them?

And if you care about the owner and group of a long-term mountpoint, 
it's one command to create it and one more to change the owner and group.

> In fact, I prefer to have even a visible indicator, of mount points, and a
> kind of response to say "the file system on this mount point is currently
> not available", other than some scripts or commands just failing with a "not
> found". Therefor I add a single empty file in mount point directories with
> the name "not mounted", nowner:nogroup, mode 0000. The mount point
> permissions are set to fit there later usage. If you try to list the
> directory content you get a "not mounted" entry displayed.
> 
> I know this is preference, but not everybody does it the same way, and I
> won't try to force anybody to do something similar, but I know several
> people who like to not being stuck at this root:root semantic.

Sure, that's a valid choice.  And you are free to set it up that way:

# using permissions that Debian uses
for FS in /dev/mqueue /dev/shm; do
	mkdir -p -m 1777 $FS
	touch $FS/"not mounted"
	chown -R noowner:nogroup $FS
done
#and mount mqueue/shm manually or with mount -T -a

It just doesn't seem like something to do with an option or configuration
line to a stock utility.

It *would* make sense to allow creating leading directories "manually"
in mdev.conf; the rule would presumably have to be a generic one executed
unconditionally upon "mdev -s".
This would let us set /dev/snd/ to be root:audio 0660, and by extension
to create the mountpoints.
 
> >I will readily admit that most of that may not be something that many
> >people can come up with off the top of their head. I happen to have
> >just spent a large part of the day reading up on that sort of thing.
> 
> Sure, and my reply was not for criticism, just an explanation, why I got
> away from that fstab approach.

Yes, thanks. 

 
> >Note the x-mount.mkdir option isn't supported by Busybox yet; I've looked
> >at the code but haven't figured out how to do it yet.
> 
> Sure, we could do that ...
> 
> >(We also need to ignore x-* other than that, just to handle fstab properly.)
> 
> ... but here you fail. You can do that for BB and may be all the applets
> using fstab, but what about other programs and scripts? You get in big
> trouble, when you change any fstab format, as you have to expect to break
> someone others work.

Yes, that's a good reason why it shouldn't have been done that way.

However, util-linux developers added x-* options as a way for external
applications to store per-device comments, and some applications are
apparently already using those.

As a result, we, and others, *need* to at least ignore x-* options if 
we are going to be able to mount all entries in a standard util-linux
/etc/fstab. Adding x-mount.mkdir support will not impose an additional
burden, except for the fact that it offers sysadmins and packagers
more reasons to use an extension that could break old code.

...For what it's worth, I'm talking about using it in (hypothetical)
/etc/vfstab, rather than /etc/fstab.

> Conclusion:
> 
> - current fstab give not all required possibilities (mainly for the virtual
> file systems and device file system management)
> 
> - changing format of fstab risk breaking other things, as this file is used
> by many others programs / scripts
> 
> Therefor it is not wise to try using fstab for the intended purpose.
> 
> 
> ... on the other side mdev.conf is a BB private conf file. You may add some
> extensions, to allow for extra functionality, without breaking existing
> configurations, by just letting a single point of usage hop over some lines,
> as for comment lines.
> >mqueue	/dev/mqueue	mqueue	x-mount.mkdir=1300	0 0

> Long syntax, compared to the intended mdev.conf format, compatible in format
> of other entries there:

> mqueue  root:root  1300  %mqueue

> The first mqueue is the mount point name which get prefixed by /dev when not
> starting with a slash (as other entries).
> 
> *Remember*: Those lines are just detected and ignored (as comments) by
> normal device operations.

First, request for clarification--does that mean:
mountpoint	owner:group	chmod	%fstype

as it appears to?

Second, I note that in my example, "mode 1300" is the mode of the mqueue
entry in devtmpfs, as visible if you run:

mkdir newdev && mount -o bind /dev newdev && ls -ld newdev/mqueue

/dev/mqueue, as mounted, is by default chmod 1777 (which seems rather lax
to me); the point of my example was that you can have different
permissions for the directory and the mount.
(Personally, I tend to think that it's better to make an unmounted
directory unwriteable, so that if someone tries writing to it without
realizing that it's unmounted, they don't create files on the wrong
fs.)

So in your example, is 1300 the mode for the directory entry that
mqueue is mounted on, the mode for the root of the mqueue filesystem,
or of both?
Is "root:root" the mountpoint before mounting, the mountpoint after
mounting, or something else?
(If you're not talking about the mountpoint before mounting, 
it would be nice to see an explanation in terms of the equivalent
mkdir/chmod/chown/mount.)

There are a few other things I'm wondering about your example:
- how do you pass options to mount in your example?
- can you set the source name to something meaningful, rather than 
having it always be "none" (yes, this is aesthetic) ?
- how does this address submounts of /sys (such as cgroups) ?

> >On a typical system, this would be done by hand, with a service file
> >or adding "mkdir /dev/mqueue && mount -t mqueue /dev/mqueue" to a
> >script.
> 
> Ack ... done a thousand times ... before I stopped ... took a deep breath
> ... and started to migrate to a different approach:
> 
> Not describing how my systems are that up (which may very between systems),
> but to describe what shall be set up.
> 
> That is, a list of required mount points, mounts, symlinks, directories,
> etc., and a single uniform handler script (system depended) reading that
> table, and performing the required operation.

Apart from the mounts, sounds a lot like "makedevs".

> Which differs in the point, as usual startup scripts tend to mix the
> information what to setup with the commands how to setup.
> 
> This approach even lead (unexpectedly), to a more or less novice (without
> shell script knowledge) being able to setup different system layouts, by
> just changing a single file with a uniform syntax ... it made my head
> spinning, seeing which complex system that novice has set up with that
> approach. A perfectly working system, were even experts neglected being able
> to hack something critical (which was never expected).
> 
> Putting such (device file system related) things into mdev.conf is just the
> consequence of that approach, when using mdev.

While I like the general concept of having only one authoritative source,
having that source be mdev.conf seems like you're asking for mdev to
become the One Tool to rule them all. ;)
I mean that feature creep seems to be the natural consequence, not
that your *goal* is to have mdev become "full system initialization in
one command".

Might I suggest that you step back and ask yourself if there's a way to
mark this information to make it easy to split into the various
components, so that you can maintain more in one place without
requiring all your tools to expand in features?

Also, I really am interested in what this looks like/lets you do
(in the sense of wanting to start experimenting some more.)

Thanks,
Isaac Dunham