trace mode by default

[Clemens Lang]

Hi,

On Fri, Jan 12, 2018 at 02:42:06PM +0100, db wrote:
> I gave it a try just to see where it would stop or what clues would I
> get in the logs and it didn't even extract, although from a glimpse
> into porttrace.tcl the program used (AFAIR) should have been in the
> allowed system directories. Then extracted manually and continued only
> to stop on a script that seemingly run tools from allowed directories.

If you're running a development version of MacPorts on High Sierra,
you're probably hitting
  https://trac.macports.org/ticket/55575
See [1] for previous discussion. You can revert [2] locally to work
around this for now.

Don't bother trying to make a Go build work with trace mode though.
Trace mode relies on library injection using DYLD_INSERT_LIBRARIES, but
Go's threading implementation requires that it can hook into the system
very early, which does not work when DYLD_INSERT_LIBRARIES is set.
There's nothing we can do about the Go ports.


> Would you mind roughly defining trace mode since it's not documented
> in the manpages nor in the guide?

There's a snippet in the 'port(1)' manpage:

| -t
|     Enable trace mode debug facilities on platforms that support it,
|     currently only Mac OS X.
|

In a nutshell, trace mode sets DYLD_INSERT_LIBRARIES to inject a library
into each process run by a port's build system. This library hooks all
relevant filesystem-related system calls.

The injected code connects to a socket offered by MacPorts that provides
a simple protocol: First, a list of deny/allow/ask rules is transferred.
Accesses to files in the allow list are immediately granted, access to
files in the deny list are immediately denied and accesses to files
matching ask rules send a request over the socket to the server, which
tests whether the file in question was installed by a port in the
transitive set of dependencies of the port that is currently built.
Based on the outcome of this test, the server replies and the library
injected into the processes allows access to the file, or returns an
error while setting errno in a way that processes think the file does
not exist.

This simulates a clean build environment for a port, which reduces the
problems caused by external interference (conflicting ports, headers and
libraries in /usr/local, etc).


The port(1) manpage continues:

|     This feature is two-folded. It consists in automatically detecting
|     and reporting undeclared dependencies based on what files the port
|     reads or what programs the port executes. In verbose mode, it will
|     also report unused dependencies for each stage of the port
|     installation. It also consists in forbidding and reporting file
|     creation and file writes outside allowed directories (temporary
|     directories and ${workpath}).

However, this paragraph is actually wrong now. This used to be correct,
but trace mode has since changed to be a 'deny-and-let-the-build-fail'
sandbox rather than a 'trace-and-suggest-missing-dependencies' sandbox,
like it used to be.

If you want to help out, it would be nice to update the documentation on
trace mode. [3] is the source for the port(1) manpage. We could probably
even add a port-trace(7) manpage to explain the feature. The source for
the guide [4] is at [5]. A subsection in '3. Using MacPorts' or '6.
MacPorts Internals' could probably be dedicated to trace mode.

Let me know if you have any questions.

[1] https://lists.macports.org/pipermail/macports-dev/2017-December/037025.html.
[2] https://github.com/macports/macports-base/commit/3d4c9b342d28abd0b7aaf7eb70fa4862e898542c#diff-94a7b4a6e8f8c93116146f83a92a7f44
[3] https://github.com/macports/macports-base/blob/master/doc/port.1.txt
[4] https://guide.macports.org/
[5] https://github.com/macports/macports-guide

-- 
Clemens