From owner-freebsd-arch@FreeBSD.ORG Thu Aug 8 20:06:00 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4FF6A803 for ; Thu, 8 Aug 2013 20:06:00 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 09FA32FD7 for ; Thu, 8 Aug 2013 20:05:59 +0000 (UTC) Received: from Julian-MBP3.local (etroy.elischer.org [121.45.226.51]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.6) with ESMTP id r78K5nMf092158 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 8 Aug 2013 13:05:52 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5203FA18.20403@freebsd.org> Date: Fri, 09 Aug 2013 04:05:44 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: Re: Reliable process tracking References: <20130804134658.GC35080@stack.nl> <20130807201934.GA4918@stack.nl> In-Reply-To: <20130807201934.GA4918@stack.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 20:06:00 -0000 On 8/8/13 4:19 AM, Jilles Tjoelker wrote: > On Mon, Aug 05, 2013 at 01:13:10PM +0200, Edward Tomasz Napierała wrote: >> Wiadomość napisana przez Jilles Tjoelker w dniu 4 sie 2013, o godz. 15:46: >>> When shutting down a service or requesting status, rc.subr currently >>> uses a combination of pidfiles and process names. This is fairly but not >>> completely reliable once it is set up correctly (which can take a lot of >>> work and possibly patching the daemon to use pidfile(3) from our >>> libutil). It is also incapable of killing multiprocess daemons such as >>> CGI web servers without cooperation of the daemon. >>> I think what is needed here is a facility that marks a process and all >>> of its descendants. Removing the mark should be a privileged or at least >>> an unusual operation; no unprivileged function specified by POSIX such >>> as setsid() should do this. >> I've actually thought about that when I added setloginclass(2). It's >> trivial to modify rc.subr to use su(8) to set login class for each >> service. It should be trivial to modify pkill(1) and killall(1) to >> add "-c" option to kill all processes in a given login class. > There are some problems with su -c: > > * It refuses to set a login class name that is not in /etc/login.conf. > Given that multiple instances of a service should each have their own > kernel login class, it may make sense to allow specifying the > login.conf entry separate from the kernel login class. I've been pondering the possibility of appending a universe (jail) number to the UIDS, PIDS and various other things. (classes maybe?). It wouldn't have to be everywhere, but ther eare a number of places where comparisons would DTRT if they were comparing "my_jail+my_uid" with "his_jail+his_uid", instead of just the UIDs. It would also help with the "multiple roots" problem, and might simplify some of the current code. Unfortunately we already extend PIDS to make thread IDs but we could still grab a bunch of bits way up the top end to express jail-IDs. > > * It always inserts an intermediate process to shut down the PAM session. > This is not needed to start a simple daemon but not that harmful apart > from performance. > >> Two caveats: >> 1. Login classes, just like UIDs, are global, not per jail. This means when >> you want to kill all processees in a login class, you should probably use >> "-j" option to limit it to a given jail, e.g. jail 0. > True. > >> 2. I'm not sure if pkill(1) has any special way of handling this, but there is >> an obvious race condition between iterating over processes in userland >> in pkill(1) and quickly forking processes to kill. Perhaps we should have >> some kind of syscall to do it in a race-free way? > Yes. >