Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 29 May 2019 16:32:22 +0200
From:      Stefan Esser <se@freebsd.org>
To:        Theron <theron.tarigo@gmail.com>, soc-status@freebsd.org
Cc:        Bakul Shah <bakul@bitblocks.com>, freebsd-hackers@freebsd.org, freebsd-ports@freebsd.org
Subject:   Re: GSoC: Separation of Ports Build Process from Local Installation
Message-ID:  <baf38e00-2fb1-1907-0883-e6b5e29c7ab2@freebsd.org>
In-Reply-To: <5cdb1c0b-a2dd-c754-daa3-187330ad9ad6@gmail.com>
References:  <5cdb1c0b-a2dd-c754-daa3-187330ad9ad6@gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Am 29.05.19 um 00:51 schrieb Theron:
> Hello All,
> 
> For Google Summer of Code 2019 I am working on FreeBSD's ports tree makefiles
> towards eliminating the dependency of the ports building process on the local
> system's installed packages.  Currently this level of separation can only be
> accomplished in practice through chroot or Jail.  The project will eliminate
> the need for cooperation of the root user since /usr/local will not need to be
> touched.
> 
> The major technical obstacle to be overcome is that ports expect to find files
> of their dependencies installed in /usr/local.  To support this without
> touching that location on the installed system, file accesses will be
> redirected to a location controlled by the ports build process through use of
> a library to intercept file accesses.
> 
> Once I have that working (well enough to build one port at a time) I will move
> on to modify bsd.port.mk itself (and related files) to utilize this mechanism
> for virtual installation of port dependencies during builds.
> 
> The full project proposal can be seen at
> https://docs.google.com/document/d/1B30U9csgY299W59tNraSX1LYjzsba2i04OrYAUpdIZs/edit
> .

What's wrong with using chroot to provide a clean build environment?

That is what synth does, and I have been using my re-implementation of
portmaster for this purpose for some time, which uses a chroot jail with
read-only null-mounts of all relevant file systems and a clean copy of
some files and directories in /etc and /var that can be written without
root privileges. The jail is set up in not measurable time (irrelevant
compared to the time required to build the port).

The only problem with this approach is that it requires extra disk space
for the build environment (e.g., the specific C compiler required by some
port) plus the work space for the actual port build process. I'm using
tmpfs file systems within the jail for the work directory and the copies
of parts of /etc and /var that need to be written to.

Is there a risk of mis-use of the interception library to attack the
system, BTW?

[Its use is not restricted to root and it might be used to re-map file
system paths for commands that check e.g. policy files to decide whether
some operation is authorized ... SUID programs should not be vulnerable
to such an attack (since they do not allow the library pre-load required
to intercept the file operations), but there might be application programs
that are restricted by non-writable files in hard-coded directories that
could be subverted this way ... (such a command would be ill-designed,
since any user could compile her own interception library, but providing
such a library with the system and possibly having hooks for it in libc
might simplify such an attack, especially if there is no compiler and
easy way to install such a library on a host).]

> My goal is that this work can be integrated well enough into /usr/ports/Mk so
> that unlike Jail, no set up work should be required for using ports tree to
> build a set of installable packages.

Yes, this might be beneficial. But there will be huge differences
compared to the current build process. And in the end you'll probably
have to put the logic used by, e.g., portmaster to track dependencies
and determine the availability of up-to-date packages (to use as build
dependencies) into the ports system.

> Please let me know if you are interested in this project; feedback is
> appreciated.  If someone would like to provide ongoing feedback or mentorship
> that would be especially helpful.  Bakul Shah is my mentor officially for GSoC
> but I would be happy to have additional support from someone who is
> experienced with internals of the port infrastructure makefiles.

I'd be interested to get further information about your approach and
the progress you make and my experience working on a somewhat similar
project with portmaster might allow me to answer questions or provide
some help ...

Regards, STefan



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?baf38e00-2fb1-1907-0883-e6b5e29c7ab2>