From: ebiederm@xmission.com (Eric W. Biederman)
To: Aleksa Sarai <asarai@suse.de>
Cc: Aleksa Sarai <ASarai@suse.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Aleksa Sarai <cyphar@cyphar.com>,
Jess Frazelle <acidburn@google.com>,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] sched: debug: use task_pid_vnr in /proc/$pid/sched
Date: Sat, 05 Aug 2017 22:50:00 -0500 [thread overview]
Message-ID: <87h8xlicd3.fsf@xmission.com> (raw)
In-Reply-To: <d312a69af58e68a64a1332e8327cbe99@suse.de> (Aleksa Sarai's message of "Sun, 06 Aug 2017 03:58:27 +1000")
Aleksa Sarai <asarai@suse.de> writes:
> On 2017-08-06 02:52, Aleksa Sarai wrote:
>> It appears as though the addition of the PID namespace did not update
>> the output code for /proc/$pid/sched, which made it trivial to figure
>> out whether a process was inside &init_pid_ns from userspace (making
>> container detection trivial[1]). This lead to situations such as:
>>
>> % unshare -pf head -n1 /proc/self/sched
>> head (10047, #threads: 1)
>>
>> Fix this by just using task_pid_vnr for the output of /proc/$pid/sched.
>> All of the other uses of task_pid_nr in kernel/sched/debug.c are from a
>> sysctl context and thus don't need to be namespaced.
>>
>> [1]: https://github.com/jessfraz/amicontained
>>
>> Cc: <stable@vger.kernel.org>
>> Cc: Jess Frazelle <acidburn@google.com>
>> Signed-off-by: Aleksa Sarai <asarai@suse.com>
>> ---
>> kernel/sched/debug.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
>> index 4fa66de52bd6..a06acbe33e16 100644
>> --- a/kernel/sched/debug.c
>> +++ b/kernel/sched/debug.c
>> @@ -876,7 +876,7 @@ void proc_sched_show_task(struct task_struct *p,
>> struct seq_file *m)
>> {
>> unsigned long nr_switches;
>>
>> - SEQ_printf(m, "%s (%d, #threads: %d)\n", p->comm, task_pid_nr(p),
>> + SEQ_printf(m, "%s (%d, #threads: %d)\n", p->comm, task_pid_vnr(p),
>> get_nr_threads(p));
>> SEQ_printf(m,
>> "---------------------------------------------------------"
>
> Added Eric to Cc.
Changing this to pid_nr_ns, to make this relative to the pid namespace
of proc would be very reasonable.
Making files content relative to current is in general a bug.
Hiding the fact you are contained is not an explicit goal. But making
those things that are reasonably in a namespace relative to that
namespace is.
Eric
prev parent reply other threads:[~2017-08-06 3:58 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-05 16:52 [PATCH] sched: debug: use task_pid_vnr in /proc/$pid/sched Aleksa Sarai
2017-08-05 17:58 ` Aleksa Sarai
2017-08-06 3:50 ` Eric W. Biederman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h8xlicd3.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=ASarai@suse.com \
--cc=acidburn@google.com \
--cc=asarai@suse.de \
--cc=cyphar@cyphar.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.