linux-kernel - [PATCH 0/1] proc: make /proc/self point to thread

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: <20130827143938.GA19425@redhat.com>
Date:	Tue, 27 Aug 2013 16:39:38 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Willy Tarreau <w@....eu>, Al Viro <viro@...iv.linux.org.uk>,
	Andy Lutomirski <luto@...capital.net>,
	Ingo Molnar <mingo@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux FS Devel <linux-fsdevel@...r.kernel.org>,
	Brad Spengler <spender@...ecurity.net>
Subject: [PATCH 0/1] proc: make /proc/self point to thread

On 08/26, Linus Torvalds wrote:
>
> On Mon, Aug 26, 2013 at 11:09 AM, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> >
> > Patch looks ok to me, but since this has never worked and nobody has
> > actually complained, I can't really convince myself that this is
> > critical.
>
> Actually, let's back-track..
>
> Did you try the other approach? Make /proc/self point to the thread
> instead of the task?

Yes, I thought about this. But I agree with Eric, we probably need
another magic link, /proc/thread or whatever.

And. I think that s/task_pid/task_tgid/ in proc_fd_permission()
makes sense anyway. It is not only for /proc/self, why we should
restrict the access to /proc/<sub-thread>/fd ?

> The thread-group leader seems to have these extra files:
>
>  - autogroup, coredump_filter, mountstats, net, task
>

Note really afaics. Yes, tgid_base_stuff and tid_base_stuff differ,
but proc_root_lookup() uses tgid_base_stuff in any case, so
/proc/<tid>/ also has task,mountstats,etc even if it is not leader.

> Yes, it would be semantically different,

And I am afraid this can break things. But I leave this to you and Eric.

Personally I think that /proc/self pointing to "current" is better, and
in fact I was surprised when I recently found that this is not true.
But perhaps it is too late to change this old behaviour.

> but it would mean that
> "/proc/self/fd/" would actually make sense in a way that it currently
> does *not* - which would seem fairly important, since the primary use
> for it tends to be /dev/stdin.

I think this doesn't matter "in practice", normally all threads have
the same ->files. Who needs CLONE_THREAD without CLONE_FILES ?

> And the other semantic differences might be much harder to notice.
> Worth testing?

Perhaps... Well, if Andrew takes this patch (assuming you and Eric
ack it), we can see if we have any bug reports.

Oleg.

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