Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751348AbdHFD60 (ORCPT ); Sat, 5 Aug 2017 23:58:26 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:33233 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751223AbdHFD6Y (ORCPT ); Sat, 5 Aug 2017 23:58:24 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Aleksa Sarai Cc: Aleksa Sarai , Peter Zijlstra , Ingo Molnar , Aleksa Sarai , Jess Frazelle , linux-kernel@vger.kernel.org, stable@vger.kernel.org References: <20170805165226.31398-1-asarai@suse.com> Date: Sat, 05 Aug 2017 22:50:00 -0500 In-Reply-To: (Aleksa Sarai's message of "Sun, 06 Aug 2017 03:58:27 +1000") Message-ID: <87h8xlicd3.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1deChj-00045J-9j;;;mid=<87h8xlicd3.fsf@xmission.com>;;;hst=in01.mta.xmission.com;;;ip=67.3.213.87;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX18guw6bToIiEb/lPCamElItDzJVMJz2O8Q= X-SA-Exim-Connect-IP: 67.3.213.87 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.7 XMSubLong Long Subject * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.4948] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa02 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_01 4+ unique symbols in subject X-Spam-DCC: XMission; sa02 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Aleksa Sarai X-Spam-Relay-Country: X-Spam-Timing: total 5659 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 3.3 (0.1%), b_tie_ro: 2.3 (0.0%), parse: 1.26 (0.0%), extract_message_metadata: 36 (0.6%), get_uri_detail_list: 3.3 (0.1%), tests_pri_-1000: 13 (0.2%), tests_pri_-950: 2.1 (0.0%), tests_pri_-900: 1.75 (0.0%), tests_pri_-400: 30 (0.5%), check_bayes: 28 (0.5%), b_tokenize: 11 (0.2%), b_tok_get_all: 7 (0.1%), b_comp_prob: 3.9 (0.1%), b_tok_touch_all: 3.0 (0.1%), b_finish: 0.85 (0.0%), tests_pri_0: 523 (9.2%), check_dkim_signature: 0.90 (0.0%), check_dkim_adsp: 4.9 (0.1%), tests_pri_500: 5042 (89.1%), poll_dns_idle: 5033 (88.9%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH] sched: debug: use task_pid_vnr in /proc/$pid/sched X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1843 Lines: 61 Aleksa Sarai 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: >> Cc: Jess Frazelle >> Signed-off-by: Aleksa Sarai >> --- >> 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