linux-kernel - Re: [PATCH 1/6] proc: implement support for automounts in task directories

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] [day] [month] [year] [list]

Date:	Tue, 06 Jan 2009 04:20:55 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Alexey Dobriyan <adobriyan@...il.com>, viro@...iv.linux.org.uk,
	linux-kernel@...r.kernel.org, containers@...ts.osdl.org,
	sds@...ho.nsa.gov, jmorris@...ei.org
Subject: Re: [PATCH 1/6] proc: implement support for automounts in task directories

Christoph Hellwig <hch@...radead.org> writes:

> On Tue, Jan 06, 2009 at 02:32:41AM +0300, Alexey Dobriyan wrote:
>> This is current version of /proc/net as separate file system patchset,
>> rebased, etc. I'll put it into -next again when merge window closes.
>
> I still don't see the point for that.  Why not /proc/nets/<netid> with
> symlinks from /proc/<pid>/net into those?

Simple really.

/proc/nets/<netid> is the other possible viable solution.  Where netid
is some pid value that we assign to the network namespace during
unshare or clone.  While there is precedent of using a pid value
to identify a process group or a session it is a bit of a stretch
to have it cover a namespace.

When I talked it over with Al his preference was to for the
current approach, and it happens to be my preference as well.

It gives more control of naming policy to user space allowing us to
avoid the maintenance pain that is sysfs where user space depends upon
a fixed kernel naming policy (which makes change hard).

It gives us a guarantee that we only have a single dentry tree for
any given network namespace.

It allows us to eventually separate out maintenance of proc/generic
and proc/net, as inherently they have nothing in common.

The only cost of this is that we actually use one of the rare but
fully supported vfs features, on demand submounts.

Beyond that proc has wanted to be several filesystems for ages, and doing
it this way allows us to actually start splitting proc up without breaking
backwards compatibility with out existing user space.

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