From owner-freebsd-questions@FreeBSD.ORG Thu Jul 21 16:30:55 2011 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BBF3106566B for ; Thu, 21 Jul 2011 16:30:55 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 275E48FC15 for ; Thu, 21 Jul 2011 16:30:54 +0000 (UTC) Received: by wwe6 with SMTP id 6so1393945wwe.31 for ; Thu, 21 Jul 2011 09:30:54 -0700 (PDT) Received: by 10.227.164.79 with SMTP id d15mr402257wby.62.1311265854214; Thu, 21 Jul 2011 09:30:54 -0700 (PDT) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id ff6sm1183222wbb.49.2011.07.21.09.30.52 (version=SSLv3 cipher=OTHER); Thu, 21 Jul 2011 09:30:53 -0700 (PDT) Message-ID: <4E28543A.5020307@my.gd> Date: Thu, 21 Jul 2011 18:30:50 +0200 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: freebsd-questions@freebsd.org References: <20110721100259.GA5326@external.screwed.box> <4E283D86.7080407@my.gd> <20110721151919.GC7553@external.screwed.box> <4E284726.50704@my.gd> <20110721161150.GD7553@external.screwed.box> In-Reply-To: <20110721161150.GD7553@external.screwed.box> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Subject: Re: build ports from not a root user? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 16:30:55 -0000 On 7/21/11 6:11 PM, Peter Vereshagin wrote: > Oh freebsd-questions want you buy me a mersedes benz? > 2011/07/21 17:35:02 +0200 Damien Fleuriot => To freebsd-questions@freebsd.org : > DF> On 7/21/11 5:19 PM, Peter Vereshagin wrote: > DF> > Oh freebsd-questions want you buy me a mersedes benz? > DF> > 2011/07/21 16:53:58 +0200 Damien Fleuriot => To freebsd-questions@freebsd.org : > DF> > > DF> > DF> > I'd like to build my ports from not a root user. > DF> > DF> > DF> > DF> That is possible but exceedingly highly inconvenient. > DF> > DF> What is the reason for doing that ? > DF> > > DF> > Security. Because of the limitations the non-root user can have. > DF> > This should decrease the probability of the bad port to ruin the system during > DF> > the build process. > DF> > Such a thing can be happening only in a specific conditions due to the > DF> > particular build environment and can or can not be a subject of a port author's > DF> > intentions. > DF> > The good admin practice exclamates that if the task does not need the > DF> > permission than it should not have it. Building of a a single port is certainly > DF> > one of those situations. > DF> > > DF> > DF> While compiling the port itself doesn't require root privileges, > DF> installing it does. > > Yes. > > DF> This in turn means the whole "make install clean" chain requires root > DF> privileges. > > but 'make all' does not require root privileges under those conditions: > > 1. all dependencies are already installed > 2. write access to the port directory > > so it's pretty simple to replace 'make all install' from the root into the > > # su user make > # make install > > the dependencies, every of them, to behave like this is the my question. > Well, you could always check a port's dependencies like so: cd /usr/ports/editors/texmacs grep DEPENDS Makefile The problem is if there are many dependencies, it won't show all of them, as per the example below: BUILD_DEPENDS= tex:${PORTSDIR}/print/teTeX-base LIB_DEPENDS= guile.20:${PORTSDIR}/lang/guile \ RUN_DEPENDS= tex:${PORTSDIR}/print/teTeX-base Notice the \ at the end of LIB_DEPENDS indicating another dependency but without the "LIB_DEPENDS=" beginning. I suppose it can still be dealt with. Once you've obtained your list of deps, you can always build each of them by hand. Of course some might also have dependencies in turn so you'll have to loop around a bit... Also, you'll run into trouble running ldconfig as a non-root user, should that be needed when building a port. > DF> If you're concerned that *compiling* a port will break the system, I > DF> can't see how, the ports are built in a temporary directory. > > And? > Can you show please the connection between the two: > > 1. ports are built in a temporary directory > 2. compiling a port can not break the system > > Thank you. > Seeing the port is built in a temporary directory *and* you have access to the makefiles used by the port, you can easily ensure no existing system parts will be overwritten. > DF> If you're concerned about a port being rogue and causing malicious > DF> commands while building it, then you shouldn't build that port at all, > DF> even with non-root privileges. > > I can never know this for sure before I do. > Port maintainer and port author may not know this too. > Check the port's makefiles. This is going to be tedious though... > The particular example is perl build systems, the Build.PL. It can do > everything and I'm more afraid of it than the traditional Makefile-based perl > build systems. > Then this becomes a matter of trusting or not the perl port that you installed. Seeing the downloaded distfile has its checksums verified, it then becomes a matter of trusting the ports tree itself to guarantee that the perl package has not been altered. > DF> But the separate commands are started with the privileges of the > DF> currently running portupgrade process. > > And the separate command can not drop its porivileges from root? > Apparently this hasn't been implemented, possibly the author, like me, couldn't see any reason he would want to do that. > DF> And since you need to be root to use portupgrade... ;) > DF> > DF> Port managers interact with pkgdb and such, which also require root > DF> privileges. > > They need this only to install the every particular port but they do not need > root privileges to build it. > Again I can see no real reason to implement this. If you're concerned about damage while compiling the port, what about damage when running the port's binary ? You're complicating things by reinforcing security on one side and leaving the other completely unchecked. Remember security is like a chain, only as strong as the weakest link.