linux-kernel - [PATCH 0/12] Schedule find_task_by

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

Date:	Tue, 29 Jan 2008 16:38:36 +0300
From:	Pavel Emelyanov <xemul@...nvz.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	devel@...nvz.org, Oleg Nesterov <oleg@...sign.ru>
Subject: [PATCH 0/12] Schedule find_task_by_pid() for removal

The function in question finds the task by its pid_t in an
initial pid namespace (init_pid_ns). This is no longer safe to
simply call it, since the current task may be in a pid namespace 
and it may return the wrong task.

The proper behavior is to call the find_task_by_vpid() if the 
caller is sure, that the target task lives in the same namespace 
as he is, or the find_task_by_pid_ns() and specify the namespace 
to find a task in.

Since the find_task_by_pid() is a well-known API call, and its
semantics changes, I think that it's better to mark it as 
deprecated to warn people, that the result may differ from what 
they expect and force them to use proper call.

Another case is to store the pointer to the struct pid of a desired
task and later call the pid_task() to get the task itself.

So this set just fixes the existing users of find_task_by_pid().
The only one will be left - the UML mconsole, but I'm completely
lost in this code, finding out what kind of pid is passed in
the mconsole_stack() call :(

Singed-off-by: Pavel Emelyanov <xemul@...nvz.org>
--
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/