From owner-freebsd-stable@freebsd.org Fri Nov 29 16:55:39 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0CAD91B5CCC for ; Fri, 29 Nov 2019 16:55:39 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from ihor-5.amdmi3.ru (ihor-5.amdmi3.ru [185.238.136.130]) by mx1.freebsd.org (Postfix) with ESMTP id 47PgcT6scjz45y3 for ; Fri, 29 Nov 2019 16:55:37 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from amdmi3.ru (localhost [IPv6:::1]) by ihor-5.amdmi3.ru (Postfix) with SMTP id A05A213BC6 for ; Fri, 29 Nov 2019 19:55:33 +0300 (MSK) Received: by amdmi3.ru (nbSMTP-1.00) for uid 1001 amdmi3@amdmi3.ru; Fri, 29 Nov 2019 19:55:33 +0300 (MSK) Date: Fri, 29 Nov 2019 19:45:09 +0300 From: Dmitry Marakasov To: freebsd-stable@freebsd.org Subject: Re: How can kill(-1, 0) return EPERM? Message-ID: <20191129164509.GE4071@hades.panopticon> References: <20191129151606.GD4071@hades.panopticon> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20191129151606.GD4071@hades.panopticon> User-Agent: Mutt/1.12.1 (2019-06-15) X-Rspamd-Queue-Id: 47PgcT6scjz45y3 X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of amdmi3@amdmi3.ru has no SPF policy when checking 185.238.136.130) smtp.mailfrom=amdmi3@amdmi3.ru X-Spamd-Result: default: False [4.41 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_MEDIUM(0.99)[0.989,0]; DMARC_NA(0.00)[amdmi3.ru]; NEURAL_SPAM_LONG(1.00)[0.998,0]; R_SPF_NA(0.00)[]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:48666, ipnet:185.238.136.0/22, country:RU]; MIME_TRACE(0.00)[0:+]; IP_SCORE(0.42)[ip: (-0.18), ipnet: 185.238.136.0/22(0.48), asn: 48666(1.78), country: RU(0.01)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2019 16:55:39 -0000 * Dmitry Marakasov (amdmi3@amdmi3.ru) wrote: > I'm helping to investigate some userspace issue [1], where kill(-1, SIGKILL) > fails with EPERM. I've managed to isolate this case in a small program: > > > ``` > #include > #include > #include > #include > #include > #include > > int main() { > if (setuid(66) == -1) // uucp, just for the test > err(1, "setuid"); > > int res = kill(-1, 0); // <- fails with EPERM > fprintf(stderr, "kill(-1, 0) result=%d, errno=%s\n", res, strerror(errno)); > > return 0; > } > ``` > > when run from root on 12.1 kill call fails with EPERM. However I cannot > comprehend what it is caused by and how it's even possible: kill(2) manpage > says that with pid=-1 kill should only send (and in this case of sig=0, > /not/ send) signals to the processes belonging to the current uid, so there > should be no permission problems. I've also looked into the kernel code > (sys_kill, killpg1), and it matches to what manpage says, I see no way > for it to return EPERM: sys_kill() should fall through to the switch, call > killpg1() with all=1 and killpg1() if(all) branch may only set `ret` to > either 0 or ESRCH. Am I missing something, or is there a problem somewhere? It looks like I have misread the `else if' path of this core. if (all) { /* * broadcast */ sx_slock(&allproc_lock); FOREACH_PROC_IN_SYSTEM(p) { if (p->p_pid <= 1 || p->p_flag & P_SYSTEM || p == td->td_proc || p->p_state == PRS_NEW) { continue; } PROC_LOCK(p); err = p_cansignal(td, p, sig); if (err == 0) { if (sig) pksignal(p, sig, ksi); ret = err; } else if (ret == ESRCH) ret = err; PROC_UNLOCK(p); } sx_sunlock(&allproc_lock); } ... so it's clear now where EPERM comes from. However it looks like the behavior contradicts the manpage - there are no signs of check that the signalled process has the same uid as the caller. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: https://github.com/AMDmi3