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

[Harald Becker]

On 16.03.2015 00:53, Isaac Dunham wrote:
> 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

Yes I know that x-* mount options approach, but I don't see it has very 
wide spread (yet).


> My own idea was to make mount recognize "-d" as a signal that it should
> create the mountpoint if needed.

AFAIK something similar is the BSD approach, but that doesn't matter it 
can be of general use. The disadvantage is, it doesn't solve the missing 
owner, group, and permission setting.


> -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.

... you forget the case, where something in system startup fails, and a 
not so experienced admin need to look, what's failing in the system :(

Sorry, I know being picky on the permissions look ugly, but you never 
mind what sorts of failures I came across. Someday I started to set the 
permissions to help me in discovering unusual behavior, and after some 
time I found it very handy to have the permissions of all mount points 
set. I found others roll there eyes when say came across, but some time 
later they start adapting and liking this. Not everybody, but several 
did. Preference!


> 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.

Not every mount point is long-term mount point. Not everybody mounts 
there file systems on startup and unmount before shutdown. An unmounted 
file system is more save to damages than a mounted. Therefor it may be 
of use to setup the mount points correct, as soon as the file system is 
unmounted, the mount point still shows up with some reasonable permissions.


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

And anybody else is free to setup it the way they like.


> # 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

Sure, and another time scattered around some system setup information in 
any scripts. Where as I like to have a table, what to set up and not how 
to setup.


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

My intention is to get a few simple one-shot startup commands, that get 
there system setup related information from some central tables.

I don't think putting this into mount / fstab is a good choice, but 
putting all device file system related information in mdev.conf is at 
least, for me no doubt.

If you widen your acceptance to proc and sys, is pure preference, and 
can be done with no extra cost (to nobody, who dislikes and leave such 
things out of there mdev.conf). All the intended extensions are required 
for some operation on device file system (e.g. devpts, mqueue, shm, fd, 
stdin, stdout, stderr). So they are clearly device file system related.


> 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".

Now you are coming to my xdev -i. Mounting is only for things like 
devpts, but the problem is, it has to be done in the right order with 
other operations, so the easiest way is, to put the mount information 
for those virtual file systems in mdev.conf and call mount with the 
right arguments, just as done in a shell script. Nothing is setup 
automatically, but you can setup all things the way you like. From a 
central place.


> 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.

Sure, ignoring them in BB could be wise.


> /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.

It is difference, if you actively support a not so beautifully 
extension, or silently ignore them, not breaking things.


> First, request for clarification--does that mean:
> mountpoint	owner:group	chmod	%fstype
>
> as it appears to?

yes, the percent sign triggers mount operation

Or better in addition (full intended syntax):

mountpoint owner:group mode %fstype [=device] [options]

--> mount -t fstype -o options device mountpoint

Where the default of device is the literal "virtual", but doesn't 
matter, as it is only for humans readability.

The default for options is the empty string (leaving out the -o).


> /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.

Aren't there any mount options for the filesystem type to set the 
default permissions? Ahh, looks like there left such things out :(

Nevertheless, the intended extensions would allow to fix this to your 
wishes:

mqueue  root:root 0755 %mqueue
mqueue/ root:root 1300

The second line is to create directories and setup there permissions,
but they shall skip the creation, when the directory is already there.

dirname/  owner:group mode

The slash at the end of dir name triggers this type of rule, but 
mountpoint above may also end in a slash (for compatibility).

So you create the mount point with root:root, 0755, mount the mqueue 
mile system and afterwards you change the permissions of the mounted 
file system to 1300.

Isn't that more intuitive than digging through the shell scripts to find 
the place where things get setup to see / change the mode value for example?


> (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.)

Ack, that's what I'm doing, making it unwritable, but readable (an ls 
the shows up with "not mounted").


> 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?

For the created mount point directory, I thought of both, but this is 
wrong, as the mounted file system may bring it's own permission 
settings, and we would go to disturb them, when always overwriting.
... but with a little help of a second line, you may get 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.)

It's roughly (without error checks):
   mkdir mountpoint
   chown owner:group
   chmod mode
   mount -t fstype -o options device mountpoint
Where the mkdir, chown, chmod are skipped, when the directory already exist.


> There are a few other things I'm wondering about your example:
> - how do you pass options to mount in your example?

I think I answered this above.


> - can you set the source name to something meaningful, rather than
> having it always be "none" (yes, this is aesthetic) ?

yes :)  (default is "virtual" ... have I mentioned I hate that "none"?)

mqueue/ me:yours 0755 %mqueue =gugux und,das,sind,optionen
mqueue/ root:nogroup 1300

# from first line
mkdir /dev/mqueue
chown me:yours /dev/mqueue
chmod 0755 /dev/mqueue
mount -t mqueue -o "und,das,sind,optionen" gugux /dev/mqueue
# from second line
# mkdir /dev/mqueue not done as already exists
chown root:nogroup /dev/mqueue
chmod 1300 /dev/mqueue


> - how does this address submounts of /sys (such as cgroups) ?

:)

path names which do not start with a slash are relative to /dev, but 
when starting with a slash they are absolute (e.g. /sys/cgroups)


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

Which started as lengthy list of mknod commands in a shell script, 
before I send the author my criticism voting for a more table driven 
version, but as his reaction was to slow, I stumbled away from this and 
never used it again.


> 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. ;)

Nope, the primary function of mdev.conf is device file system, where the 
proc and sys (including subsystems) are a maybe (preference).

Technically it would be possible to extend the usage to other stuff like 
/tmp, but this is not my intention.

As in shell scripts, it is up to the maintainer, which entries he places 
in mdev.conf. So the maintainer has full control, over who setup what 
and how.


> 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".

You mean, what possible is, will be done? May be, but then you need to 
beg those who throw there crap into mdev.conf ... ok, I know: "Those who 
build guns, are not responsible for anybody killed." :(

Ok, good argument, but can we do anything against this, except putting a 
clear description of this in docs/mdev.txt, saying those features are 
for setting up the device file system. Using /dev as the starting point 
for relative names, was one small step solving this argument.


> 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?

I'm unsure what are you asking.

... do you mean splitting of the mdev.conf files?

In the other thread I already suggested an include feature for mdev.con, 
e.g.

#include /etc/mdev-extra.conf

... but also allow for including all files from a directory:

#include /etc/mdev.d/

... but I expect, this was not your intention

... so just clarify your question please.


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

My usual steps of development are: Planning, hacking, testing on my 
machines, giving to those who like for more testing, solving complains, 
then pushing into mainstream. Does that solve your fears? Before I'm 
even trying to put that into the official BB version, you may grab a 
patch, build on your own and test it.

I highly dislike pushing untested code into official distributions. My 
intention is to get those extension there, but not at the cost of 
bringing every bodies system down to the ground -> send me to hell, if I 
ever even think of that!

--
Harald