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

[Harald Becker]

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.


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

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.


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

... because any changing of that file format may have consequences you 
never will expect ahead. fstab is a critical beast, read and acted on by 
several other programs and (even worser) system management scripts.

Isaac, I've spend hours over hours reading up such things in the last 25 
to 30 years. I know, that it's difficult to dig into this and get 
everything right. That's the reason why I prefer planning my steps, 
before I even hack a single line of code.


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

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.


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

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.


>> ... beside that i think it's always a good idea to have the possibility to
>> overwrite the name of the default table (e.g. when your root file system
>> including etc is read only).
>
> That's a very good point, which I had not thought about.

This is the sense of discussing intended changes, before hacking code. 
More brains may gather more informations belonging to the planned work, 
avoiding unnecessary wrong ways, or at least having the possibility of 
having an early opt out (to chose a different way).

--
Harald