From owner-svn-src-all@FreeBSD.ORG Mon Mar 10 09:46:45 2014 Return-Path: Delivered-To: svn-src-all@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 ESMTPS id 300669B6; Mon, 10 Mar 2014 09:46:45 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id E0A23DC8; Mon, 10 Mar 2014 09:46:44 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 75E245297; Mon, 10 Mar 2014 09:46:38 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 6775C1C11; Mon, 10 Mar 2014 10:46:10 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Robert Watson Subject: Re: svn commit: r262566 - in stable/10: crypto/openssh crypto/openssh/contrib/caldera crypto/openssh/contrib/cygwin crypto/openssh/contrib/redhat crypto/openssh/contrib/suse crypto/openssh/openbsd-comp... References: <201402271729.s1RHT2rx075258@svn.freebsd.org> <201403031536.33679.jhb@freebsd.org> Date: Mon, 10 Mar 2014 10:46:09 +0100 In-Reply-To: (Robert Watson's message of "Sun, 9 Mar 2014 14:49:14 +0000 (GMT)") Message-ID: <864n36e68u.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: svn-src-stable@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, svn-src-stable-10@freebsd.org, John Baldwin X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 09:46:45 -0000 Robert Watson writes: > Most userspace tools that support Capsicum will explicitly test for a > kernel generating ENOSYS due to non-support and 'fail open' by not > using sandboxing. That strategy becomes more complex as applications > become more complex, and in the long term we'll want to move away from > conditional support. In the mean time, I'd generally recommend that > any code being used on 9.x support runtime detection of Capsicum -- > either via feature_is_present(3) or ENOSYS back from cap_enter(). The > ugly bit is whether or not to use other sandboxing techniques (e.g., > chroot()) if Capsicum can't be found, since that stuff tends to be > pretty messy. In this particular case, we fall back to essentially the same mechanism as without Capsicum, i.e. setrlimit(2). And we're talking 10 / 11, not 9... DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no