build ports from not a root user?

Peter Vereshagin peter at vereshagin.org
Thu Jul 21 17:46:23 UTC 2011 

Oh freebsd-questions want you buy me a mersedes benz?
2011/07/21 18:30:50 +0200 Damien Fleuriot <ml at my.gd> => To freebsd-questions at freebsd.org :
DF> On 7/21/11 6:11 PM, Peter Vereshagin wrote:
DF> > Oh freebsd-questions want you buy me a mersedes benz?
DF> > 2011/07/21 17:35:02 +0200 Damien Fleuriot <ml at my.gd> => To freebsd-questions at freebsd.org :
DF> > DF> On 7/21/11 5:19 PM, Peter Vereshagin wrote:
DF> > DF> > Oh freebsd-questions want you buy me a mersedes benz?
DF> > DF> > 2011/07/21 16:53:58 +0200 Damien Fleuriot <ml at my.gd> => To freebsd-questions at freebsd.org :
DF> > DF> >
DF> > DF> > DF> > I'd like to build my ports from not a root user.
DF> > DF> > DF> 
DF> > DF> > DF> That is possible but exceedingly highly inconvenient.
DF> > DF> > DF> What is the reason for doing that ?
DF> > DF> > 
DF> > DF> > Security. Because of the limitations the non-root user can have.
DF> > DF> > This should decrease the probability of the bad port to ruin the system during
DF> > DF> > the build process.
DF> > DF> > Such a thing can be happening only in a specific conditions due to the
DF> > DF> > particular build environment and can or can not be a subject of a port author's
DF> > DF> > intentions.
DF> > DF> > The good admin practice exclamates that if the task does not need the
DF> > DF> > permission than it should not have it. Building of a a single port is certainly
DF> > DF> > one of those situations.
DF> > DF> > 
DF> > DF> 
DF> > DF> While compiling the port itself doesn't require root privileges,
DF> > DF> installing it does.
DF> > 
DF> > Yes.
DF> > 
DF> > DF> This in turn means the whole "make install clean" chain requires root
DF> > DF> privileges.
DF> > 
DF> > but 'make all' does not require root privileges under those conditions:
DF> > 
DF> >     1. all dependencies are already installed
DF> >     2. write access to the port directory
DF> > 
DF> > so it's pretty simple to replace 'make all install' from the root into the
DF> > 
DF> >     # su user make
DF> >     # make install
DF> > 
DF> > the dependencies, every of them, to behave like this is the my question.
DF> > 
DF> 
DF> Well, you could always check a port's dependencies like so:
DF> 
DF> cd /usr/ports/editors/texmacs
DF> grep DEPENDS Makefile
DF> 
DF> The problem is if there are many dependencies, it won't show all of
DF> them, as per the example below:
DF> BUILD_DEPENDS=  tex:${PORTSDIR}/print/teTeX-base
DF> LIB_DEPENDS=    guile.20:${PORTSDIR}/lang/guile \
DF> RUN_DEPENDS=    tex:${PORTSDIR}/print/teTeX-base
DF> 
DF> Notice the \ at the end of LIB_DEPENDS indicating another dependency but
DF> without the "LIB_DEPENDS=" beginning.
DF> 
DF> I suppose it can still be dealt with.

I suppose portupgrade deals.

DF> Once you've obtained your list of deps, you can always build each of
DF> them by hand.
DF> 
DF> Of course some might also have dependencies in turn so you'll have to
DF> loop around a bit...
DF> 
DF> Also, you'll run into trouble running ldconfig as a non-root user,
DF> should that be needed when building a port.

As long as I saw the instructions on building from source they wre generally all like this:

    $ cd /tarball-expanded-0.x.y
    $ ./configure
    $ make
    $ su -
    # cd /tarball-expanded-0.x.y
    # make install

That important 'su -' is omitted from the ports. And it is about the security.

And... why should I want to change the file /etc/ld.so.cache before the port to
be installed?

DF> > DF> If you're concerned that *compiling* a port will break the system, I
DF> > DF> can't see how, the ports are built in a temporary directory.
DF> > 
DF> > And?
DF> > Can you show please the connection between the two:
DF> > 
DF> >     1. ports are built in a temporary directory
DF> >     2. compiling a port can not break the system
DF> > 
DF> > Thank you.
DF> > 
DF> 
DF> Seeing the port is built in a temporary directory *and* you have access
DF> to the makefiles used by the port, you can easily ensure no existing

I don't believe every regular system admin will look inside the every makefile
pf a port and the every of its dependencies (there can be thousands of them) in
order to use the port only.
I can't even say the one should.
And it's certainly not easy, at least for me. Ain't it a shame? ;-)
Meanwhile, the build systems are rather far from always to be the
makefile-based. I have mentioned the Module::Build here and I'm pretty sure
there are the analogous for many technologies other than Perl.
Even when makefile-based, the Module::Autoinstall is a think about it too.

DF> system parts will be overwritten.

This is not only the thing to care about. It's not only and all about the
security but about to keeping the system as consistent as possible preventing
it from inconsistences like BSDPAN modules when there are those ported already.

DF> > DF> If you're concerned about a port being rogue and causing malicious
DF> > DF> commands while building it, then you shouldn't build that port at all,
DF> > DF> even with non-root privileges.

Not necessarily malicious but just far from the best possible.

DF> > I can never know this for sure before I do.
DF> > Port maintainer and port author may not know this too.
DF> > 
DF> 
DF> Check the port's makefiles.

Those are not always port's and not always makefiles. This can happen to be the
Build.PL of the perl modules, or autogen.sh, or...

DF> This is going to be tedious though...

I'm just too easy one. ;-)

DF> > The particular example is perl build systems, the Build.PL. It can do
DF> > everything and I'm more afraid of it than the traditional Makefile-based perl
DF> > build systems.
DF> > 
DF> 
DF> Then this becomes a matter of trusting or not the perl port that you
DF> installed.

ok but some of the mistakes are not that easy as me.
Module::Autoinstall for instance can happen to be in the very next version of
a single perl module apparently very implicitly. This can be easily overlooked
by the port maintainer who is presumed to have all the dependencies installed
from the ports. The regular user on the other side installing that same module
may end with numerous bsdpan-* modules all of those could certainly be
installed from ports.
Such a particular situation isn't much about to be a matter of trust because:

    1. Module::Autoinstall is not a bad thing to use for Perl module. It's not
        its fault/drawback.
    2. Perl module author can have his/her own consideration about
        Makefile.PL's boilerplates to use with the module and those can be
        easily handled with the systems other than freebsd by mean of the
        approaches like tha one I propose here. It's not him/her
        fault/drawback but an additional service for the user.
    3. Port's maintainer is not expected to make installworld and make install
        the port into the freshly new world on the every new version of a perl
        module released. Even with that, (s)he should remember to look if
        those bsdpan-* packages has happened to be installed after that. It's
        just too much expectations from a port's maintainer imho. So it's not a
        him/her fault/drawback.

So whom is then it's a matter of trust to the whom?

DF> Seeing the downloaded distfile has its checksums verified, it then
DF> becomes a matter of trusting the ports tree itself to guarantee that the
DF> perl package has not been altered.
DF> 
DF> 
DF> > DF> But the separate commands are started with the privileges of the
DF> > DF> currently running portupgrade process.
DF> > 
DF> > And the separate command can not drop its porivileges from root?
DF> > 
DF> 
DF> Apparently this hasn't been implemented, possibly the author, like me,

Why are you sure it is not implemented?

DF> couldn't see any reason he would want to do that.
DF> 
DF> > DF> And since you need to be root to use portupgrade... ;)
DF> > DF> 
DF> > DF> Port managers interact with pkgdb and such, which also require root
DF> > DF> privileges.
DF> > 
DF> > They need this only to install the every particular port but they do not need
DF> > root privileges to build it.
DF> 
DF> Again I can see no real reason to implement this.
DF> 
DF> If you're concerned about damage while compiling the port, what about
DF> damage when running the port's binary ?

It's a different matter.
Modern software use a kinds of complicated build systems.
Not every program's author plays very well with all of their twists and
shouts, whistles and bells.
Not every build systems takes into the account the particular OS species,
especially if the OS is as rare as FreeBSD.
This means: Not every program's author familiar with circumstances of the
particular build system's usage on FreeBSD.
This can easily lead to the unwanted results like having the BSDPAN modules
instead of ports' ones, etc.
And by Murphy's law it certainly will.

DF> You're complicating things by reinforcing security on one side and
DF> leaving the other completely unchecked.

Yes, it's not all about security but about the overall system's consistency,
to show you what the thing I want. What I want is to prevent from, in that
sense I meant the security, perhaps erroneously.

DF> Remember security is like a chain, only as strong as the weakest link.

Yup.
Data consistency behaves like that, too.

73! Peter pgp: A0E26627 (4A42 6841 2871 5EA7 52AB  12F8 0CE1 4AAC A0E2 6627)
--
http://vereshagin.org

More information about the freebsd-questions mailing list