Re: Reflections on Trusting Trust



On Wed, 2005-Nov-30 13:36:10 +0100, Andreas Nemeth wrote:
>On Wednesday 30 November 2005 09:55, Ádám Szilveszter wrote:
>> Which practically begs the question: could we, pretty please, change the
>> defaults and stop encouraging people from downloading distfiles and
>> compiling them when using the ports tree as *root*?
>
>Second that. But I feel a little uneasy about making /usr/ports/ group
>writeable for wheel or giving it to a "normal" user on the system.

By default, /usr/ports is used to store:
- A checked-out copy of the ports tree as stored in CVS.
- INDEX-* This is hard-wired in the Makefile infrastructure
- Compilation/work directories - overridable with WRKDIRPREFIX
- distfiles - overridable with DISTDIR
- packages - overridable with PACKAGES
- portupgrade's INDEX*.db - overridable with PORTS_DBDIR

Rather than making /usr/ports writable by anyone other than root (if
you don't want to), you can create alternative locations for distfiles,
work directories (and package directories) so a normal used can download
and compile ports.

At one stage, editors/openoffice.org-1.1 wouldn't build if WRKDIRPREFIX
was set but that has been fixed. I haven't run into any other problems
(though it might be interesting for the build cluster to verify that).

Note that the only ports-related file that can't be moved out of the
ports tree is 'INDEX'. This is annoying (I'd like to be able to RO
export /usr/ports across several FreeBSD variants) but 'make index'
only uses information within the ports tree and so isn't dangerous.

>And what about the +INSTALL and +DEINSTALL scripts, some ports want to run?

I don't think any package management system has managed to avoid needing
scripts to handle some functions. This is primarily an issue if you
are installing a package because the scripts come out of your ports tree
if you built the port. (AFAIK, no ports create these scripts on the fly).

>Those I've seen, ensure that a certain user exists. Therefore they roam
>around in /etc.

And, hence, require root privileges.

>BTW, those scripts fail (of course), if /tmp is mounted with the noexec
>option.

I think the solution to this is to set PKG_TMPDIR somewhere else.

--
Peter Jeremy
_______________________________________________
freebsd-security@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@xxxxxxxxxxx"



Relevant Pages

  • Re: [HEADSUP] No more pkg_install on HEAD by default
    ... rewrite it from mastering PLIST files to mastering YAML MANIFEST ... A pkg tarball is a compressed tar archive like so: ... New Generation package management tool for FreeBSD ... It isn't going to be deprecated for at least as long as the ports tree ...
    (freebsd-current)
  • Re: cups builds on one, but rejected by another?
    ... One or the other has either a stale portaudit database or ports tree. ... Affected package: cups-base-1.3.3 ...
    (freebsd-questions)
  • Re: new package system proposal
    ... compile a typical desktop set of ports ... ... ports tree is tagged so that a snapshot can be retrieved using csup, ... a release set or other remote package repository via the -r flag. ...
    (freebsd-questions)
  • Re: How to download packages from OpenBSD.nu?
    ... If the package has no dependencies, ... If you don't have the -current ports tree handy on one of your ... This is the same web interface you can find from the ... snapshots, in /pub/OpenBSD/snapshots. ...
    (comp.unix.bsd.openbsd.misc)
  • Re: ports help please
    ... >fail with the above error generated from portaudit but portaudit is failing ... >Am I updating my ports tree correctly with cvsup? ... To update your ports tree, ... cvsupping your ports tree does not grab distfiles for ...
    (comp.unix.bsd.freebsd.misc)