Date: Thu, 21 Jul 2011 18:30:50 +0200 From: Damien Fleuriot <ml@my.gd> To: freebsd-questions@freebsd.org Subject: Re: build ports from not a root user? Message-ID: <4E28543A.5020307@my.gd> In-Reply-To: <20110721161150.GD7553@external.screwed.box> References: <20110721100259.GA5326@external.screwed.box> <4E283D86.7080407@my.gd> <20110721151919.GC7553@external.screwed.box> <4E284726.50704@my.gd> <20110721161150.GD7553@external.screwed.box>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <ml@my.gd> => 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 <ml@my.gd> => 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E28543A.5020307>