From owner-freebsd-ports@FreeBSD.ORG Sat Aug 20 18:04:45 2011 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94EC410656D4; Sat, 20 Aug 2011 18:04:45 +0000 (UTC) (envelope-from jhelfman@e-e.com) Received: from mail.experts-exchange.com (mail.experts-exchange.com [72.29.183.251]) by mx1.freebsd.org (Postfix) with ESMTP id 6C1848FC18; Sat, 20 Aug 2011 18:04:45 +0000 (UTC) Received: from mail.experts-exchange.com (localhost [127.0.0.1]) by mail.experts-exchange.com (Postfix) with ESMTP id 1F12B7005B5; Sat, 20 Aug 2011 10:46:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=e-e.com; h= content-transfer-encoding:content-type:content-type:mime-version :user-agent:from:from:subject:subject:date:date:references :in-reply-to:message-id:received:received:received; s=ee; t= 1313862374; x=1315676774; bh=5xIFEVrlMvuRWvIBy9Jh+2MFX9iq87qx/kX GPT8wzZ4=; b=X7x60WWj/6a5C4Y9RBs1lJe6EeIsdvEA9lCZTpWSqCBdYe6iJzb 1ISGoeZ8uqWMCVhccamtiq+pkZ27wEP/xYSXFn8P01bsxQlWw6OYLX0I0qZuo6pH 6twtqY+Q8WPzG0X7+I4g5X+Gban6ontZgAK/Ah+GmHUsGRYoQR5B+yD8= X-Virus-Scanned: amavisd-new at experts-exchange.com Received: from mail.experts-exchange.com ([127.0.0.1]) by mail.experts-exchange.com (mail.experts-exchange.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-d96FTTsAuj; Sat, 20 Aug 2011 10:46:14 -0700 (PDT) Received: from mail.experts-exchange.com (localhost [127.0.0.1]) by mail.experts-exchange.com (Postfix) with ESMTP id D29E5700321; Sat, 20 Aug 2011 10:46:14 -0700 (PDT) Received: from 63.201.14.88 (SquirrelMail authenticated user jhelfman) by mail.experts-exchange.com with HTTP; Sat, 20 Aug 2011 10:46:14 -0700 Message-ID: <91b826baee57a450a519fee1c7032a5c.squirrel@mail.experts-exchange.com> In-Reply-To: <4E4FBA13.4050009@FreeBSD.org> References: <4E4F95FD.907@FreeBSD.org> <20110820115203.GH17489@deviant.kiev.zoral.com.ua> <4E4FA589.7070303@FreeBSD.org> <20110820124443.GJ17489@deviant.kiev.zoral.com.ua> <4E4FBA13.4050009@FreeBSD.org> Date: Sat, 20 Aug 2011 10:46:14 -0700 From: "Jason Helfman" To: "Glen Barber" User-Agent: SquirrelMail/1.4.20 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Kostik Belousov , ports@freebsd.org Subject: Re: [Request for Comments] Adding a JAILED meta-variable to bsd.port.mk X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2011 18:04:45 -0000 > On 8/20/11 8:44 AM, Kostik Belousov wrote: >>> One thing I can think of off-hand to fix this in that case is setting a >>> local environment variable to disable a check for security.jail.jailed. >>> Would this be an ok solution for those cases? If not, I happily agree >>> that this change should not be made then. >>> >>> I have an updated patch to bsd.port.mk that looks for a local >>> environment variable, PKGJAIL - if it is set, then JAILED is unset. >>> Would this be acceptable? >> The change would require user to do a configuration for a thing that >> previously just worked. What is the point ? >> > > I suppose the specific problem I am trying to solve is a case where a > user builds a port within a jail with the expectation that the port will > in fact run within the jail with little or no changes. Perhaps > security/sshguard-pf and databases/postgresql*-server are not the most > ideal examples of where this would be relevant. > > I agree that a configuration change for something that worked before is > not the best solution. So, I retract this change proposal. > > Again, thank you for the feedback and pointing out that this would have > had negative impact on those using jails for package building. > > Regards, > > Glen > I, myself, have not installed or built enough packages in jails to find this issue, however I am using tinderbox for maintaining my ports, submitting ports, or patches, as well as maintaining a local ports tree. In doing this, and maintaining our operational environment, I am finding may conditions where you may want to do one thing or another, and the possibilities I have found can be endless, so it could be argued to not introduce global functionality for the X number of ports/packages that need it, however to code the port to be aware of these conditions in the packaging scripts. For example, you could test for values of sysctl, or another condition. Based on the result, perform X action. Although, I haven't done this specifically for a jail, I don't see why the same practice couldn't be exercised. These, I believe, can all be take taken advantage of in subsequent pkg-* files. Just a thought. Thanks, Jason