A Plea to Reduce Dependences (e.g., for swig)
M.E. O'Neill
oneill at cs.hmc.edu
Tue Aug 16 17:25:45 PDT 2011
Joshua Root wrote:
> You might just have 'macportsuser root' in your macports.conf.
Here's what I have:
% grep macportsuser /opt/local/etc/macports/*
/opt/local/etc/macports/macports.conf.default:#macportsuser macports
% grep macportsuser ~/.macports/*
(nothing)
Also, according to Directory Utility I do have a macports user.
>> Does the install part still run as root? (That would be a bit dangerous on a buildbot trusted by many.)
>
> It has to in many cases. There's code for running in a chroot, but that breaks DNS lookups (and probably more) on 10.6+.
>
> Using something along the lines of fakeroot would no doubt be safer; someone just has to implement it. I don't think there's a security regression here though, as the portfiles and upstream sources are not audited in the first place.
Actually, I'd argue that there is a significant increase in exposure.
Without a buildbot, if I install package foo, and its dependency bar, I'm at the mercy of the installers for foo and bar (and the author of the Portfile). That's not great, but maybe I trust foo and bar well enough.
On the other hand, with a buildbot, if I install foo and its dependency bar, I'm also trusting *every other package* the buildbot has built, and with a buildbot that keeps up with the ports try, *every version* of those packages. Thus, if the buildbot build dubious-baz, I am trusting that too.
This is why mock/fakeroot etc. (or rpm's approach of installing as an unprivileged user and then changing the ownership on the installed files) are very valuable, and why things have worked this way in the Linux community for many years.
M.E.O.
More information about the macports-dev
mailing list