Ignore other filesystems in the mountable devices list

[Grégory SCHMITT]

Hi Tom,

When using the mount option in e2, there's a couple of filesystem
types, dirs or devs that get ignored for good reasons and do not
appear in the list of mountable devices. I found the list in
e2_fs_mount.c, l.116.

Here's a list of a few other that, IMHO, may be ignored for clarity
purposes:
- fusectl : related to the fuse subsystem, shouldn't be open to the
end-user
- nfsd : related to the nfs subsystem, shouldn't be open to the
end-user
- tmpfs : a kernel filesystem, very rarely used by an end-user
- fuse.bindfs : an overlay filesystem which lies on the top of another
fs to dynamically modify permissions & ownership, most of the time I
use it either manually (i.e using the command line) or have it set
automatically when the underlying fs is mounted.
- /boot : normally mounted by the init system using root rights, so I
can't see any end-user wanting/being able to unmount /boot.

Attached is a quick & dirty patch made by me.

[Liviu Andronic]

Post by Grégory SCHMITT
- tmpfs : a kernel filesystem, very rarely used by an end-user

Don't know about others, but I use this for /tmp.

Post by Grégory SCHMITT
- /boot : normally mounted by the init system using root rights, so I
can't see any end-user wanting/being able to unmount /boot.

..unless the user runs emel as root, which personally I do often.

Liviu

[t***@onepost.net]

On Mon, 31 Dec 2012 16:56:09 +0100

Post by Grégory SCHMITT
When using the mount option in e2, there's a couple of filesystem
types, dirs or devs that get ignored for good reasons and do not
appear in the list of mountable devices. I found the list in
e2_fs_mount.c, l.116.
Here's a list of a few other that, IMHO, may be ignored for clarity
- fusectl : related to the fuse subsystem, shouldn't be open to the
end-user
- nfsd : related to the nfs subsystem, shouldn't be open to the
end-user
- tmpfs : a kernel filesystem, very rarely used by an end-user
- fuse.bindfs : an overlay filesystem which lies on the top of another
fs to dynamically modify permissions & ownership, most of the time I
use it either manually (i.e using the command line) or have it set
automatically when the underlying fs is mounted.
- /boot : normally mounted by the init system using root rights, so I
can't see any end-user wanting/being able to unmount /boot.

Grégory, I've posted to svn a new version of e2_fs_mount.c, inspired by your recommendation.

The [un]mountable checks are now in respective functions, which supports more flexibility (and some debug messages).

IMHO '/boot' should not be blocked. When the system is running, /boot is operationally irrelevant, and who knows what a user may wish to play with? I think we should try to exclude only those points whose change would have a chance of damaging the running system.

Maybe it's not quite right, yet, but it's better than before.

Feel free to evaluate and report.

Regards
Tom

[Grégory SCHMITT]

Le Wed, 2 Jan 2013 12:19:12 +1100,

Post by t***@onepost.net
On Mon, 31 Dec 2012 16:56:09 +0100

Post by Grégory SCHMITT
When using the mount option in e2, there's a couple of filesystem
types, dirs or devs that get ignored for good reasons and do not
appear in the list of mountable devices. I found the list in
e2_fs_mount.c, l.116.
Here's a list of a few other that, IMHO, may be ignored for clarity
- fusectl : related to the fuse subsystem, shouldn't be open to the
end-user
- nfsd : related to the nfs subsystem, shouldn't be open to the
end-user
- tmpfs : a kernel filesystem, very rarely used by an end-user
- fuse.bindfs : an overlay filesystem which lies on the top of
another fs to dynamically modify permissions & ownership, most of
the time I use it either manually (i.e using the command line) or
have it set automatically when the underlying fs is mounted.
- /boot : normally mounted by the init system using root rights, so
I can't see any end-user wanting/being able to unmount /boot.

Grégory, I've posted to svn a new version of e2_fs_mount.c, inspired
by your recommendation.
The [un]mountable checks are now in respective functions, which
supports more flexibility (and some debug messages).
IMHO '/boot' should not be blocked. When the system is running, /boot
is operationally irrelevant, and who knows what a user may wish to
play with? I think we should try to exclude only those points whose
change would have a chance of damaging the running system.
Maybe it's not quite right, yet, but it's better than before.
Feel free to evaluate and report.

So far it works ok for me (although an extra "/boot" has been forgotten
on l.2608). I'll test it more in depth & in time later and get back if
required.

Regarding /boot : I'm not running e2 as root, but if other users (such
as Liviu) do and have in interest in keeping /boot unblocked, then we
shall keep it that way. My intention was simply to avoid overloading
the mountpoint menu with entries that may be
impossible/dangerous/useless to unmount, and keep it to what people
need, which in my case is removable media management.

[Arve Barsnes]

Post by Grégory SCHMITT
Regarding /boot : I'm not running e2 as root, but if other users (such
as Liviu) do and have in interest in keeping /boot unblocked, then we
shall keep it that way. My intention was simply to avoid overloading
the mountpoint menu with entries that may be
impossible/dangerous/useless to unmount, and keep it to what people
need, which in my case is removable media management.

Agreed, I keep /boot unmounted by default, and if I wanted to use emel
to do changes there it would be annoying if it was not possible to
mount it directly.

Arve