Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 21 Jul 2011 20:11:51 +0400
From:      Peter Vereshagin <>
Subject:   Re: build ports from not a root user?
Message-ID:  <>
In-Reply-To: <>
References:  <> <> <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
Oh freebsd-questions want you buy me a mersedes benz?
2011/07/21 17:35:02 +0200 Damien Fleuriot <> => To :
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 :
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> While compiling the port itself doesn't require root privileges,
DF> installing it does.


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.

DF> The purpose of the ports is to be an easily manageable and installable
DF> collection of packages.


DF> If you're not going to use the ports' installation chain, then perhaps
DF> you should simply configure, build and install from source instead.

No, thanks. ;-)

DF> > DF> I can not come up with a scenario where one would want to do that.
DF> > 
DF> > Shall I put here the examples of the distributions those are building their
DF> > packages from a non-root user? There should certainly be the ones.
DF> > 
DF> > DF> Rather than the means you'd like to use, tell us the end you're trying
DF> > DF> to accomplish.
DF> > 
DF> > You mean about feature enhancement here, the what feature do I need in terms of
DF> > functionality and how it should make me better immediately after that.
DF> > The security isn't about ROI but it's business model is insurance.
DF> > What I need is the more security which is about to keep my things from getting
DF> > worse.
DF> > But it's not a bad thing ;-)
DF> > 
DF> If you want security, you'll want to make /usr read-only and your

How could you know? I made. But it's not only a /usr.

DF> problems will go away.

If I had them I should want them to go away.
I want them not to come.

DF> If you're concerned that upgrading a port will break existing ones
DF> because of dependencies, then use a port manager (portmanager,
DF> portupgrade...)

I do, but it's unavoidable.

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.

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.

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.

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.

Another hypothetical example is: Module::Autoinstall-based perl modules. The
port maintainer can have their dependencies already installed from ports, so
(s)he will never even notice that install automation. But the regulare user who
installs them from scratch may end with a coup[le of BSDPAN modules despite
many of them had been already ported and should be installed from ports and not
via the

THis can be easily prevented with my proposal.

DF> > DF> In other terms: what are you trying to do ? (and don't tell me "building
DF> > DF> a port as a non root user")
DF> > DF> 
DF> > DF> 
DF> > DF> > How can I tell the ports system that it should su ( switch user ) before to
DF> > DF> > build the dependencies?
DF> > DF> 
DF> > DF> I don't think you can.
DF> > DF> 
DF> > DF> 
DF> > DF> > Can portupgrade handle this?
DF> > DF> 
DF> > DF> Nope.
DF> > 
DF> > But it seem to handle the dependencies in the every separate 'make' command?
DF> > I suppose it should have a tweak to do the 'make install' on the every port in
DF> > the dependencies chain in the 'su -' parameter.
DF> > Think I will dig it out. One day.
DF> > But I'm pretty sure there's anyone on the list who knows this from
DF> > portupgrade's sources.
DF> > 
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?

DF> And since you need to be root to use portupgrade... ;)
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.

DF> You do not want to tinker with that.
DF> This is, imho, not a correct approach to security.
DF> > DF> > Dependencies should be installed from a root user.
DF> > DF> And the rest of your ports too.
DF> > 
DF> > It's not a problem that I'm asking about.
DF> > If I install the port I know the permissions I want for this.
DF> > But the ports system may not know that I need the separate environment details
DF> > for building.
DF> > I think there should be a tweak for this, either in ports or in portupgrade,
DF> > that's a question.
DF> > 
DF> I don't understand your statement, perhaps you could rephrase it.

Forget it, I'm an easy one. ;-)

73! Peter pgp: A0E26627 (4A42 6841 2871 5EA7 52AB  12F8 0CE1 4AAC A0E2 6627)

Want to link to this message? Use this URL: <>