rev-upgrade and checking for +universal dependencies (and build dependencies)

Clemens Lang cal at macports.org
Sun Jun 9 19:10:47 UTC 2024


On Sat, Jun 08, 2024 at 01:10:50PM +0200, René J.V. Bertin wrote:
> On Saturday June 08 2024 09:46:34 Clemens Lang wrote:
> 
> > Using library preloading – which does not currently work against
> > Apple's binaries on Apple Silicon Macs.
> 
> But those aren't installed through MacPorts. Does it matter here
> whether SIP & family are enabled or not, btw?

With SIP disabled, one can add a kernel boot argument to allow user
space to use Apple's ABI with pointer authentication, which would allow
building a copy of tracelib that works on those binaries.

I'm not aware that anybody has successfully done that.

It doesn't matter whether those are installed through MacPorts. Builds
use many of those binaries (e.g., the Shell, or clang), and trace mode
doesn't work on those binaries, rendering it essentially useless.
Additionally, attempting to inject those binaries causes the program to
be killed by the kernel, i.e., things break.


> > Tracelib only works on spawned subprocesses, not the MacPorts tclsh
> > process itself, so in order for that to work, rev-upgrade would have
> > to spawn a separate process, which it currently does not.
> 
> For this particular case that should be a trivial detail. The
> rev-upgrade procedure does not itself spawn any helper processes at
> the moment, correct?

Correct, but it's not really trivial, it would require a significant
rewrite and a way to communicate the results across the process
boundary.


> The elegance and security of a single command that can be written to
> handle all possible error situations. Plus you're not crippling any
> functionality at all.

Sure, but if I weigh that against the effort to implement it, it's not
worth it in my book.


> BTW, in terms of evaluation dependents of a shared library: would it
> suffice to remove read and/or execute permissions from the file rather
> than making the file disappear completely? If so it might already be
> enough to do that for just the file owner, provided the rev-upgrade
> scan is run as that user.  I suppose that files are normally owned by
> root in a normal MP installation...

Many Unix operating systems, including macOS, do not actually care about
file permissions when you are root:

:) root at cBookMax:/tmp# ls -lash test
8 ----------  1 root  wheel     4B Jun  9 21:09 test
:) root at cBookMax:/tmp# cat test
foo

-- 
Clemens



More information about the macports-dev mailing list