From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751450AbdJCTa5 (ORCPT ); Tue, 3 Oct 2017 15:30:57 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:56903 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750812AbdJCTaz (ORCPT ); Tue, 3 Oct 2017 15:30:55 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Linus Torvalds Cc: =?utf-8?Q?J=C3=BCrg?= Billeter , Andrew Morton , Oleg Nesterov , Michael Kerrisk , Filipe Brandenburger , David Wilcox , hansecke@gmail.com, Linux Kernel Mailing List References: <20170909094008.49983-1-j@bitron.ch> <20170929123058.48924-1-j@bitron.ch> <20171002162041.a7cefe8af71327b8becd2347@linux-foundation.org> <87o9pogbf7.fsf@xmission.com> <1507013157.2304.48.camel@bitron.ch> <878tgse1c5.fsf@xmission.com> <87shf0b33q.fsf@xmission.com> Date: Tue, 03 Oct 2017 14:30:36 -0500 In-Reply-To: (Linus Torvalds's message of "Tue, 3 Oct 2017 10:02:53 -0700") Message-ID: <87wp4c81wj.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=1dzStz-00029t-Cp;;;mid=<87wp4c81wj.fsf@xmission.com>;;;hst=in02.mta.xmission.com;;;ip=67.3.200.44;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+DzJTXCSN4FT15+jppSS7g8kjo3/mlms0= X-SA-Exim-Connect-IP: 67.3.200.44 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 1.5 TR_Symld_Words too many words that have symbols inside * 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.4072] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa06 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: *;Linus Torvalds X-Spam-Relay-Country: X-Spam-Timing: total 5680 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 2.8 (0.0%), b_tie_ro: 1.95 (0.0%), parse: 0.82 (0.0%), extract_message_metadata: 13 (0.2%), get_uri_detail_list: 1.40 (0.0%), tests_pri_-1000: 7 (0.1%), tests_pri_-950: 1.14 (0.0%), tests_pri_-900: 0.96 (0.0%), tests_pri_-400: 21 (0.4%), check_bayes: 20 (0.4%), b_tokenize: 6 (0.1%), b_tok_get_all: 7 (0.1%), b_comp_prob: 1.96 (0.0%), b_tok_touch_all: 3.5 (0.1%), b_finish: 0.53 (0.0%), tests_pri_0: 1157 (20.4%), check_dkim_signature: 0.47 (0.0%), check_dkim_adsp: 6 (0.1%), tests_pri_500: 4473 (78.8%), poll_dns_idle: 4468 (78.7%), rewrite_mail: 0.00 (0.0%) Subject: Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC 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 in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Linus Torvalds writes: > On Tue, Oct 3, 2017 at 9:36 AM, Eric W. Biederman wrote: >> >> *Scratches head* >> pdeath_signal is cleared during exec if bprm->cap_elevated. > > It's not cleared if we are *releasing* capabilities, which is exactly > what might cause a "we can no longer send a signal" *Doh* Now I see where you are coming from. >> is_setid is set if the uid != eid or gid != egid. > > Again, that may be exactly what changes - the original process may > have uid != euid, and now we're going from an "we still had a root > uid/suid" to "dropping everything to euid". > > IOW, we're _dropping_ capabilities, not adding them. Maybe we don't > want to allow signaling the original parent any more. We never signal the orignal parent. We signal the child that requested the pdeath_signal when the original parent dies. The permission check is: Does the parent have permission to signal the child that requested the signal. So the child dropping permissions won't change the result of that permission check one iota. The parent dropping permissions may change the result of that permission check. I care about this case because we already have the pdeath_signal and the permission check doesn't make any sense to me, and appears not to be at all useful. Plus it is the only caller of group_send_sig_info outside of kernel/signal.c so I think the kernel would be more maintainable if we could simplify this piece of code. > That said, as mentioned, I actually don't think it's a real problem. > The real problem is entirely conceptual: yet more complexity in an > area that we've already had problems in before. >>From the conversation so far it does appear we can do better. Eric