From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761357AbdEVUsX (ORCPT ); Mon, 22 May 2017 16:48:23 -0400 Received: from mx2.suse.de ([195.135.220.15]:58202 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751824AbdEVUsT (ORCPT ); Mon, 22 May 2017 16:48:19 -0400 Date: Mon, 22 May 2017 22:48:17 +0200 Message-ID: From: Takashi Iwai To: ebiederm@xmission.com (Eric W. Biederman) Cc: linux-kernel@vger.kernel.org Subject: Re: [4.11 regression] su / sudo doesn't work when enlightenment is running as the window manager In-Reply-To: <87r2zgtzbi.fsf@xmission.com> References: <87r2zgtzbi.fsf@xmission.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.2 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 22 May 2017 22:24:17 +0200, Eric W. Biederman wrote: > > Takashi Iwai writes: > > > Hi Eric, > > > > we've got a bug report showing the weird behavior supposedly triggered > > by your commit 20523132ec5d ("exec: Test the ptracer's saved cred to > > see if the tracee can gain caps"). In short, user can't run su or > > sudo any longer when a terminal is started from Enlighentment window > > manager. > > > > Some details are found in openSUSE Bugzilla: > > https://bugzilla.suse.com/show_bug.cgi?id=1040041 > > > > and more in gentoo forum and Enlightenment bug tracker: > > https://forums.gentoo.org/viewtopic-t-1063022-postdays-0-postorder-asc-start-0.html > > https://phab.enlightenment.org/T5470 > > > > As the bug seems solely in Enlightenment, it might that be some its > > specific patch is broken. But a regression is a regression, after > > all... > > > > Could you take a look at the issue? > > I will. > > I am wondering if the bisect did not quite go back far enough as that > change really should have been had no effect and it was the introduction > of the ptracer_capable test that is causing problems. > > To be able to think this through clearly I really need to understand > what enlightenment-start is doing. > > At first glance the reported behavior does seem corect. If you are not > root and you are ptracing a setuid-root application it should not have > be run setuid. > > So either I made a stilly mistake somewhere or enlightenment is doing > something problematic. The ugly possibility is that I might have closed > a security hole they were depending upon by accident. > > I took a quick look at what I think is the code to enlightment_start. > AKA src/bin/e_start_main.c > > And all it does is: > pid = fork(); > if (pid == 0) { > /* child */ > ptrace(PT_TRACE_ME, 0, NULL); > } else { > ptrace(PT_ATTACH, pid, NULL, NULL); > ...; > } > > So the tracer_cred should be the same on either path. > > So if someone who understands what enlightenment is doing could boil > this down or otherwise help me understand exactly what kind of ptrace > interaction is causing this problem that would really help. > > Hmm. You know I think I know what is going on and it is a bit > embarrasing: > > Can someone please test this change? I am guessing I just forgot to zero > ptracer_cred on fork... Why ptrace_init_task lives in a header > instead of in kernel/fork.c I do not know. Thanks for a prompt reaction! I'll prepare a test kernel and ask reporters giving it a try. Takashi > > diff --git a/include/linux/ptrace.h b/include/linux/ptrace.h > index 422bc2e4cb6a..a31442c4b272 100644 > --- a/include/linux/ptrace.h > +++ b/include/linux/ptrace.h > @@ -202,6 +202,7 @@ static inline void ptrace_init_task(struct task_struct *child, bool ptrace) > INIT_LIST_HEAD(&child->ptraced); > child->jobctl = 0; > child->ptrace = 0; > + child->ptracer_cred = NULL; > child->parent = child->real_parent; > > if (unlikely(ptrace) && current->ptrace) { > > Eric >