linux-kernel - Re: + proc-fix-the-threaded-proc-self.patch added to -mm tree

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, 28 Nov 2007 12:47:31 -0500
From:	"Albert Cahalan" <acahalan@...il.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	"Ingo Molnar" <mingo@...e.hu>,
	"Guillaume Chazarain" <guichaz@...oo.fr>,
	akpm@...ux-foundation.org, mm-commits@...r.kernel.org,
	oleg@...sign.ru, rjw@...k.pl, roland@...hat.com, xemul@...nvz.org,
	linux-kernel <linux-kernel@...r.kernel.org>,
	"Ulrich Drepper" <drepper@...hat.com>
Subject: Re: + proc-fix-the-threaded-proc-self.patch added to -mm tree

On Nov 28, 2007 6:31 AM, Eric W. Biederman <ebiederm@...ssion.com> wrote:
> Ingo Molnar <mingo@...e.hu> writes:
> > * Albert Cahalan <acahalan@...il.com> wrote:
> >> On Nov 27, 2007 7:49 PM, Guillaume Chazarain <guichaz@...oo.fr> wrote:

> In a lot of ways if you access /proc/self and you get back information
> that does not correspond to yourself the result is nonsense.  Which
> is a fairly mighty problem.

In general, this is not a problem we have.

/proc/self points to the process, not the task group leader.

They are different. Look at /proc/*/stat, where the
per-process info is summary data. The per-thread
stat file is not summary data. This is intended to be
true for all files in /proc; there may be some with bugs.

Some of the data can not be summed up and will not
always be shared. This is legacy crud. Don't use it,
and don't try to "fix" it. It's there so that old programs
can continute to work as long as weird threading isn't
in use.

Note that it was intended that non-legacy additions
would normally be added to either the process directory
or the thread directory, not both. I think somebody may
have ripped out the ability to do this; at the very least
there have been numerous illogical additions.

> I'm still trying to understand which will break user space more,
> adding /proc/task or changing /proc/self.

Changing /proc/self makes you get per-thread data
when you asked for per-process data. That's bad.

> >> This one is probably best:
> >> /proc/task -> 123/task/456
> >> (with both numbers showing)
> >
> > this sounds good to me. If it's a symlink then there's not much other
> > choice because the thread PIDs do not even show up under /proc anymore.
>
> The name sounds good to me.
>
> I am not certain the two components make sense as we have a possible
> permission problem where it is remotely possible that a task will
> have permission to access /proc/<tid> but not /proc/<tgid>.

If it hurts, don't do that. We allow foot shooting.

> The reason I care is that we need to fix /proc/mounts.  So once we
> have /proc/task we can also have change /proc/mounts to
> be a symlink to /proc/task/mounts.
>
> Once we get the /proc/mounts thing sorted out.  There are several
> other entries in /proc that need to that need to follow in it's wake
> as they also become per namespace.  /proc/net and /proc/sysvipc for
> starters.

As I predicted, the container bloat would be a never-ending
source of bugs. You're discovering bugs where there were none.
You'll never run out of this sort of problem. Keeping Linux lean
and simple would be far better.
-
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/