linux-kernel - Re: Feature request, "create on mount" to create mount point directory on mount, implied remove on unmount

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 04 Jul 2015 23:48:28 +0100
From:	jon <jon@...shouse.co.uk>
To:	Valdis.Kletnieks@...edu
Cc:	coreutils@....org, linux-kernel@...r.kernel.org
Subject: Re: Feature request, "create on mount" to create mount point
 directory on mount, implied remove on unmount

On Sat, 2015-07-04 at 16:56 -0400, Valdis.Kletnieks@...edu wrote:
> On Fri, 03 Jul 2015 13:01:59 +0100, jon said:
> > Hi, could I make a hugely nieve user request :-)
> >
> > Would it be possible to add a new mount option to everything?
> >
> > New mount option 'com' = "create on mount" (implied remove on unmount).
> >
> >
> > Example fstab entry
> > /mounts/amountpoint	LABEL=notalwayshere	ext4,com
> 
> I'll bite.
Thank you :-)

>   What system administration problem does this solve?
Most auto mounters are based on an a system event being processed by a
user space tool. I am talking about a simple optional bit of code built
into mount() umount() calls.  So it could be an fstab entry, or typed
into a shell or any other source rather than an event processed through
user space tools in response to USB or a DVD read or similar. I am not
talking about an automount.

It solves these problems:
1) It solves the problem of processes writing data into the mount point
when not mounted (as does, I accept a user space automounter, but as I
explained the usage scenario differs). 

2) It would be useful for embedded devices, installers etc.  I do quite
a bit of work in the embedded space, sometimes running kernel+shell+user
process only, sometimes no udev, no systemd, not even full fat init.  

3) installers or similar could use such an option for mounting install
data. By specifying the flag user space processes can infer that the FS
is successfully mounted by the presence of the mount point without the
need to explicitly code against an event system or parse log files. 

3) Users can use it to have a slightly improved new mount behaviour and
also hopefully be used as a flag to indicate that "oh so clever user
space managers" should stay away entries using it in fstab.

> In particular, automount has been around in one form or another *at least*
> since SunOS3.2 in the mid 80's, and I have seen it work with huge user maps
> (10k+ users). 
Yes, but like I say automount is normally based on an event. I am simply
talking about a flag/switch that can be used for optional implied
mkdir,rmdir around calls to mount() unount() - nothing more, nothing
less !

Such a feature would mitigate the justification for some of the less
sensible behaviours of systemd or similar user space event processors.

By adding at as an option it would not break other behaviours where it
was not explicitly enabled.

To be completely clear, I am not after a kernel based auto mounter -
just a kernel based mount point creator/remover, it is not quite the
same thing !

>How did it cope for 30+ years without this feature?
By people saying "ahh bugger" when a mount fails and some process craps
out files all over the mount point directory I expect ......

<partial rant>
Or maybe by the new "improved" systemd way of failing to go multi user
when an device referenced in fstab is offline, fucking things up for
anyone without true remote administration - the price you pay for using
cheap PC hardware on a small scale, you know, like Linux cheerleaders
always claimed was its unique selling point ......  
As a bonus I would hope that systemd would take such a mount option to
mean that an FS specified in fstab would be optional, but that would
just be a bonus and is not my justification for such a a feature.
</rant>

I can probably think of other reasons, but off the top of my head it
just seems a useful behaviour to have as an option IMHO.

I know my suggestion is not as fashionable as hanging user space code
from the kernel events, but I personally would rather just have the
option natively in the kernel rather than an option for some 'pre' or
'post' mount() umount() event that some user space process needs to
handle.

Thanks,
Jon

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/