From owner-freebsd-arch@FreeBSD.ORG Sun Aug 4 14:27:22 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A8B6B6ED for ; Sun, 4 Aug 2013 14:27:22 +0000 (UTC) (envelope-from trhodes@FreeBSD.org) Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by mx1.freebsd.org (Postfix) with ESMTP id 8DE6C2AFB for ; Sun, 4 Aug 2013 14:27:22 +0000 (UTC) Received: from homiemail-a66.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by hapkido.dreamhost.com (Postfix) with ESMTP id C0AC2DD81C for ; Sun, 4 Aug 2013 07:27:16 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id E57DD35005B for ; Sun, 4 Aug 2013 07:27:09 -0700 (PDT) Received: from lab (ip72-219-240-45.dc.dc.cox.net [72.219.240.45]) (Authenticated sender: trhodes@fbsdsecure.org) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPA id AA2F9350058 for ; Sun, 4 Aug 2013 07:27:09 -0700 (PDT) Date: Sun, 4 Aug 2013 10:27:08 -0400 From: Tom Rhodes To: freebsd-arch@freebsd.org Subject: Re: Reliable process tracking Message-Id: <20130804102708.36341a8a.trhodes@FreeBSD.org> In-Reply-To: <20130804134658.GC35080@stack.nl> References: <20130804134658.GC35080@stack.nl> X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: Sun, 04 Aug 2013 14:27:22 -0000 On Sun, 4 Aug 2013 15:46:58 +0200 Jilles Tjoelker wrote: > 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. > > There is no such facility in POSIX, but there are some FreeBSD-specific > facilities that come close: > > * Do the tracking in userland using kqueue EVFILT_PROC NOTE_TRACK. I > think this does not work because there is no way to deal with > NOTE_TRACKERR. NOTE_TRACKERR could perhaps be avoided by making fork() > fail instead but that may be rather nasty if the tracking process does > not call kevent() while many tracked processes are created and > destroyed again. > > * Jails. If there were a way to put a process in jail without affecting > its privileges, filesystem root directory and network interfaces, this > would be usable. Processes cannot escape from a jail and there are > ways to signal all processes in a jail or to terminate forcibly all > processes in a jail. > > * setloginclass(2). The login class attribute cannot be changed by a > normal user, although login(1) and su(1) will change it to the > target user's class. The rctl system is also available to limit > resources based on login class; this can also be useful to kill all > processes with some login class without racing with fork(). > > * setlogin(2). Everything except setuid login(1) knows to be careful > with this, but breaking getlogin(2) seems unwise. Therefore, this is > only useful for daemons with one passwd line per instance. > > Similar facilities in other operating systems: Linux cgroups, Solaris > process contracts. There is fscd - it does a lot of what you ask for. In fact, I had talked to a few people about bringing it into base but have not really figured out how I want to integrate it into rc. -- Tom Rhodes