linux-kernel - Re: [PATCH 3/3] autofs: add ignore mount option

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:   Wed, 30 Jan 2019 10:07:15 +0800
From:   Ian Kent <raven@...maw.net>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     autofs mailing list <autofs@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Pan Bian <bianpan2016@....com>
Subject: Re: [PATCH 3/3] autofs: add ignore mount option

On Tue, 2019-01-29 at 17:16 -0800, Andrew Morton wrote:
> On Sat, 12 Jan 2019 08:00:40 +0800 Ian Kent <raven@...maw.net> wrote:
> 
> > Add an autofs file system mount option that can be used to provide
> > a generic indicator to applications that the mount entry should be
> > ignored when displaying mount information.
> 
> What is the reason for adding this feature?

In other OSes that provide autofs and that provide a mount list
to user space based on the kernel mount list a no-op mount option
("ignore" is the one use on the most common OS) is allowed so that
autofs file system users can optionally use it.

The idea is that it be used by user space programs to exclude
autofs mounts from consideration when reading the mounts list.

Prior to the change to link /etc/mtab to /proc/self/mounts all
I needed to do to achieve this was to use mount(2) and not update
the mtab but now that no longer works.

I know the symlinking happened a long time ago and I considered
doing this then but, at the time I couldn't remember the commonly
used option name and thought persuading the various utility
maintainers would be too hard.

But now I have a RHEL request to do this for compatibility for a
widely used product so I want to go ahead with it and try and
enlist the help of some utility package maintainers.

Clearly, without the option nothing can be done so it's at least
a start.

Ian