From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: ACJfBosTRlUcGWXD93VGk8MeuveltA33SNymRl/fyBlZBSyP0Ja3Xe2K+zOiaHxb3pJu6s5XFcyX ARC-Seal: i=1; a=rsa-sha256; t=1516211425; cv=none; d=google.com; s=arc-20160816; b=cw70vpsW9bfgA4fsA7cjL8ny3wCTBTnH+yT79ahESRtHUiKoOcU5RkuUutw62MsDGe wf2OhMzmmAoWNl1y10P52hl1sCctSq93emaOdxI9eNs+xvL9DKtPGh3+5W8lHi+qjn84 zTeZtBh/4UbamVBLKvpPLNko1fsQGyNhXcRteIALszimZNavv3P73QtpAAn1Il2HWYDg 7Fa+dltKPQho+8jMZweJdMnT5zoIjY/hf5kl8WwVzAnq+ZN78lYRgtIdSBPsWlUXeR4Z qEO0YS7nPm7WkFBtfU9JxcoHptBL2NVi96Rzaf2NG1j0p+XdXpVAkDaXuh24CSpFtRIT Dy0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=subject:mime-version:user-agent:message-id:in-reply-to:date :references:cc:to:from:arc-authentication-results; bh=7aO7Wwik3eroNceqCRp66WDrT9zgOeLmSRe2pBxctLE=; b=eCSwi8rM46xiunN4fTaSDCbNBiWN/BoN8+BVQx6Wxr5fDUFnQ/k/gOgr3Iq3A4Dye1 WB/H6Td0nUj30JDuJXT/qaeUTdy5ZyFNv18uBBI7ivvtt1AHh+hFDqEUoDuU1sOaTnxE oWWDAKkOh4sxidrv/eRjNhY1nyv2MAvwBrtVRE+tgV1xQWmZ0aC1t6Cu8fP03lHbwsKO GN5cxwj8e7mNQf4tk9ygXzlkV5Byl39zbUx1eSRnG6FMRV4UyrGYOhF4+255ZCSM+Nq6 kZ3mEreGbGiOQ242VY7CcqS8cXQzgAomgldGknDkHpIjKzkpXf1+n/iiXoA3cxWkpi/g QZiQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of ebiederm@xmission.com designates 166.70.13.233 as permitted sender) smtp.mailfrom=ebiederm@xmission.com Authentication-Results: mx.google.com; spf=pass (google.com: domain of ebiederm@xmission.com designates 166.70.13.233 as permitted sender) smtp.mailfrom=ebiederm@xmission.com From: ebiederm@xmission.com (Eric W. Biederman) To: Oleg Nesterov Cc: Kirill Tkhai , gregkh@linuxfoundation.org, jslaby@suse.com, linux-kernel@vger.kernel.org References: <151619233415.5683.18062849657787533510.stgit@localhost.localdomain> <151619277281.5683.16110625178528288163.stgit@localhost.localdomain> <87shb4floe.fsf@xmission.com> <20180117173415.GA7964@redhat.com> Date: Wed, 17 Jan 2018 11:49:31 -0600 In-Reply-To: <20180117173415.GA7964@redhat.com> (Oleg Nesterov's message of "Wed, 17 Jan 2018 18:34:15 +0100") Message-ID: <87tvvke5p0.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=1ebrqx-0003NN-Ei;;;mid=<87tvvke5p0.fsf@xmission.com>;;;hst=in02.mta.xmission.com;;;ip=97.121.73.102;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+6zasmqAg/GrO6HzX+pfZO8qOtyJUWXEA= X-SA-Exim-Connect-IP: 97.121.73.102 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.7 XMSubLong Long Subject * 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.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa01 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_01 4+ unique symbols in subject * 0.0 T_TooManySym_02 5+ unique symbols in subject X-Spam-DCC: XMission; sa01 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Oleg Nesterov X-Spam-Relay-Country: X-Spam-Timing: total 507 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 2.9 (0.6%), b_tie_ro: 1.92 (0.4%), parse: 1.21 (0.2%), extract_message_metadata: 26 (5.1%), get_uri_detail_list: 2.6 (0.5%), tests_pri_-1000: 10 (2.0%), tests_pri_-950: 2.0 (0.4%), tests_pri_-900: 1.60 (0.3%), tests_pri_-400: 29 (5.6%), check_bayes: 27 (5.3%), b_tokenize: 11 (2.1%), b_tok_get_all: 7 (1.3%), b_comp_prob: 4.0 (0.8%), b_tok_touch_all: 2.3 (0.5%), b_finish: 0.73 (0.1%), tests_pri_0: 422 (83.3%), check_dkim_signature: 0.84 (0.2%), check_dkim_adsp: 4.4 (0.9%), tests_pri_500: 7 (1.4%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH v2 1/3] Revert "do_SAK: Don't recursively take the tasklist_lock" 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) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1589843366609121628?= X-GMAIL-MSGID: =?utf-8?q?1589862911777418073?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: Oleg Nesterov writes: > On 01/17, Eric W. Biederman wrote: > >> Kirill Tkhai writes: >> >> > This reverts commit 20ac94378de5. >> > >> > send_sig() does not take tasklist_lock for a long time, >> > so this commit and the problem it solves are not relevant >> > anymore. >> > >> > Also, the problem of force_sig() is it clears SIGNAL_UNKILLABLE >> > flag, thus even global init may be killed by __do_SAK(), >> > which is definitely not the expected behavior. >> >> Actually it is. >> >> SAK should kill everything that has the tty open. If init opens the tty >> I am so sorry, it can not operate correctly. init should not have your >> tty open. > > OK, but then we need "force" in other places too. __do_SAK() does send_sig(SIGKILL) > in do_each_pid_task(PIDTYPE_SID) and if signal->tty == tty. > > Plus force_sig() is not rcu-friendly. > > So I personally agree with this change. Whether we want to kill the global init > or not should be discussed, if we want to do this __do_SAK() should use > SEND_SIG_FORCED and this is what Kirill is going to do (iiuc), but this needs > another patch. To operate correctly, do_SAK() needs to kill everything that has the tty open. Unless we can make that guarantee I don't see the point of changing do_SAK. It would be better to give up on do_SAK altogether than to keep do_SAK limping along and failing to meet it's security guarantees. If there are real world races, let's document those and say do_SAK has been broken for X number of years and just remove it. Right now that seems the more reasonable course. Unless there truly is someone using do_SAK to ensure they have a tty all to themselves. Eric