Non-root port/package installs
Ade Lovett
ade at FreeBSD.org
Tue Feb 8 14:28:28 PST 2005
Michael C. Shultz wrote:
> And my point is, if a port is being installed or removed from anywhere
> other than the users own home it should fail.
I don't agree. There is a perfectly good setup to invoke su, sudo, or
whatever, as part of the build/install process.
Why force people to needlessly spend time compiling large chunks of
software, whilst running as root. There are significant dangers doing so.
The obvious comeback to this is "well, build as non-privileged, and
install as root". So instead of:
user% make install
[compile]
prompt for root password:
[install]
you're now forcing people to do:
user% make
[...]
user% sudo make install
[...]
which only works in the degenerate case of a single port not bringing in
ANY other dependencies. If there are dependencies which don't exist,
the port would error out somewhere at that first 'make' step, as it gets
around to 'make install' on a dependency.
Since this has already been taken care of with the various "su" targets
within the ports infrastructure, it makes sense to actually USE it.
> Seems like to test this idea of yours on the package build cluster
> would require trying to install and remove a port to the base system to
> make sure it fails, then to install and remove it from the
> non-privileged user's home to insure it succeeds. That is a
> unnecessary waste of time.
Wrong. As far as build clusters go, the EXISTING infrastructure allows
for the build to occur as a non-privileged user, only elevating
privileges when absolutely needed. Very, very useful if you care about
not executing potentially long-running, complex, very hard to "prove
correct" jobs.
> This sounds like a function of the ports system to deal with, deciding
> privileges vs ability to install where and when. No need for individual
> ports to deal with this.
Wrong again. The infrastructure for doing privilege-seperation of port
build/installs already exists. There's absolutely no need for
individual ports to reinvent this particular wheel.
The issue here is simply one that, given the existing infrastructure, it
makes far more sense to fix the privilege issues on a tree-wide basis
than doing individual ports, one at a time.
Indeed, after the initial major flurry of activity getting the existing
tree in line, one could easily argue that package building clusters MUST
run as much as possible of their builds as a non-privileged user.
Using existing infrastructural code. Not per-port hacks.
-aDe
More information about the freebsd-ports
mailing list