linux-kernel - Re: [PATCH 5/8] kernfs: let objects opt-in to propagating from the initial namespace

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]

Message-ID: <20200413203716.GK60335@mtj.duckdns.org>
Date:   Mon, 13 Apr 2020 16:37:16 -0400
From:   Tejun Heo <tj@...nel.org>
To:     Christian Brauner <christian.brauner@...ntu.com>
Cc:     Jens Axboe <axboe@...nel.dk>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, linux-block@...r.kernel.org,
        linux-api@...r.kernel.org, Jonathan Corbet <corbet@....net>,
        Serge Hallyn <serge@...lyn.com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Saravana Kannan <saravanak@...gle.com>,
        Jan Kara <jack@...e.cz>, David Howells <dhowells@...hat.com>,
        Seth Forshee <seth.forshee@...onical.com>,
        David Rheinsberg <david.rheinsberg@...il.com>,
        Tom Gundersen <teg@...m.no>,
        Christian Kellner <ckellner@...hat.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Stéphane Graber <stgraber@...ntu.com>,
        linux-doc@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH 5/8] kernfs: let objects opt-in to propagating from the
 initial namespace

Hello,

On Mon, Apr 13, 2020 at 09:59:15PM +0200, Christian Brauner wrote:
> Right, pid namespaces deal with a single random identifier about which
> userspace makes no assumptions other than that it's a positive number so
> generating aliases is fine. In addition pid namespaces are nicely

I don't see any fundamental differences between pids and device numbers. One
of the reasons pid namespace does aliasing instead of just showing subsets is
because applications can have expectations on what the specific numbers should
be - e.g. for checkpoint-restarting.

> hierarchical. I fear that we might introduce unneeded complexity if we
> go this way and start generating aliases for devices that userspace

It adds complexity for sure but the other side of the scale is losing
visiblity into what devices are on the system, which can become really nasty
in practice, so I do think it can probably justify some additional complexity
especially if it's something which can be used by different devices. Even just
for block, if we end up expanding ns support to regular block devices for some
reason, it's kinda dreadful to think a situation where all devices can't be
discovered at the system level.

> already knows about and has expectations of. We also still face some of
> the other problems I mentioned.
> I do think that what you say might make sense to explore in more detail
> for a new device class (or type under a given class) that userspace does
> not yet know about and were we don't regress anything.

I don't quite follow why adding namespace support would break existing users.
Wouldn't namespace usage be opt-in?

Thanks.

-- 
tejun