linux-kernel - Re: /etc/fstab.d yes or not

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 20 Jan 2012 17:13:12 +0100
From:	Kay Sievers <kay.sievers@...y.org>
To:	Roger Leigh <rleigh@...elibre.net>
Cc:	Karel Zak <kzak@...hat.com>, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, util-linux@...r.kernel.org
Subject: Re: /etc/fstab.d yes or not

On Fri, Jan 20, 2012 at 16:49, Roger Leigh <rleigh@...elibre.net> wrote:
> On Fri, Jan 20, 2012 at 03:04:44PM +0100, Karel Zak wrote:
>>  I'd like to add support for /etc/fstab.d to libmount. The library is
>>  currently used by mount, umount and mount.nfs. The goal is to use it
>>  on more places.
>>
>>  The /etc/fstab.d directory has been requested by people who maintains
>>  large number of mountpoints etc.
>>
>>  The directory is not replacement for /etc/fstab, it's additional place
>>  where you can describe your filesystems.
>
> As a general comment, I would like to use fstab.d for replacing
> the initscripts which mount kernel filesystems in Debian initscripts
> (sysvinit).  We currently hardcode the logic to mount each filesystem
> and additionally hardcode the defaults, and permit the defaults to
> be overridden by the user via /etc/default/* or via entries in
> /etc/fstab.  This could be done much more straightforwardly using
> entries such as /etc/fstab.d/kernfs and /etc/fstab.d/tmpfs etc.

It is just very wrong to expose kernel filesystems to system mounts.
Please invent your own config if you want that for packaging. The
kernel filesystems do not belong in fstab, and for the same reason not
in fstab.d/.

> From the distributor's POV, this can then take advantage of the
> package manager's conffile handling, meaning it's much simpler
> for the user to customise.
>
> From the initscripts POV, were systemd to also use the same
> approach, we could then share the configuration between the different
> init systems.

The init systems need to handle the mounts, but unlikely by sharing
additional config files. For systemd it is a solved problem, we don't
need fstab.d/ for that, and sysv should not start to try to solve it
at that level, because it will conflict with systemd.

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