Sandbox denies access when prefix/portdbpath not normalised

[jwhowse4]

I am running Mac OS 10.7.5 and Xcode 4.6.3. I just upgraded to Macports 2.2.0 and I receive the following error when trying to install a package. Although I use a specific example below, in fact I can not install any package since upgrading Macports. I suspect this error is related to the new use of the sandbox. Note that I have Macports installed in a non-standard location, specifically /opt/macports. I am not sure who to CC on this ticket.

port -v install pspp +graph +gui +quartz
--->  Computing dependencies for pspp.
--->  Fetching distfiles for pspp
--->  pspp-0.8.0a.tar.gz doesn't seem to exist in /opt/macports/var/macports/distfiles/pspp
--->  Attempting to fetch pspp-0.8.0a.tar.gz from http://distfiles.macports.org/pspp
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
--->  Attempting to fetch pspp-0.8.0a.tar.gz from http://sea.us.distfiles.macports.org/macports/distfiles/pspp
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
--->  Attempting to fetch pspp-0.8.0a.tar.gz from http://mirrors.ibiblio.org/gnu/ftp/gnu/pspp
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 5437k  100 5437k    0     0  64976      0  0:01:25  0:01:25 --:--:-- 75337
--->  Verifying checksums for pspp
--->  Checksumming pspp-0.8.0a.tar.gz
--->  Extracting pspp
--->  Extracting pspp-0.8.0a.tar.gz
/usr/bin/gnutar: pspp-0.8.0: Cannot mkdir: Operation not permitted
/usr/bin/gnutar: pspp-0.8.0/configure: Cannot open: No such file or directory
/usr/bin/gnutar: pspp-0.8.0/OChangeLog: Cannot open: No such file or directory
/usr/bin/gnutar: pspp-0.8.0/examples: Cannot mkdir: No such file or directory
/usr/bin/gnutar: pspp-0.8.0/examples/automake.mk: Cannot open: No such file or directory
/usr/bin/gnutar: pspp-0.8.0/examples/regress_categorical.sps: Cannot open: No such file or directory
/usr/bin/gnutar: pspp-0.8.0/examples/OChangeLog: Cannot open: No such file or directory
/usr/bin/gnutar: pspp-0.8.0/examples/repairs.sav: Cannot open: No such file or directory
/usr/bin/gnutar: pspp-0.8.0/examples/hotel.sav: Cannot open: No such file or directory
/usr/bin/gnutar: pspp-0.8.0/examples/physiology.sav: Cannot open: No such file or directory

...

/usr/bin/gnutar: Error exit delayed from previous errors
Command failed:  cd "/opt/macports/var/macports/build/_Volumes_User_Disk_opt_macports_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_pspp/pspp/work" && /usr/bin/gzip -dc '/opt/macports/var/macports/distfiles/pspp/pspp-0.8.0a.tar.gz' | /usr/bin/gnutar --no-same-owner -xf - 
Exit code: 2
Error: org.macports.extract for port pspp returned: command execution failed
Warning: targets not executed for pspp: org.macports.activate org.macports.extract org.macports.patch org.macports.configure org.macports.build org.macports.destroot org.macports.install
Please see the log file for port pspp for details:
    /opt/macports/var/macports/logs/_Volumes_User_Disk_opt_macports_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_pspp/pspp/main.log
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets
Error: Processing of port pspp failed

[neverpanic (Clemens Lang)]

Assigning to jmr.

[neverpanic (Clemens Lang)]

Please attach main.log.

[neverpanic (Clemens Lang)]

Is your /opt/macports/ a symlink?

[neverpanic (Clemens Lang)]

Also reported on IRC, with /opt/local/var/macports being a symlink.

[larryv (Lawrence Velázquez)]

Has duplicate #39760.

[jwhowse4]

Replying to cal@…:

Is your /opt/macports/ a symlink?

The entire /opt directory is a symlink. This was done in order to place /opt on a different physical disk than the operating system.

[neverpanic (Clemens Lang)]

So the issue here is that while the sandbox profile does contain the path before resolving symlinks, the kernel seems to check the path against the sandbox boundaries after resolving any symlinks.

[jwhowse4]

Replying to jwhowse4@…:

Replying to cal@…:

Is your /opt/macports/ a symlink?

The entire /opt directory is a symlink. This was done in order to place /opt on a different physical disk than the operating system.

Do you think it would resolve the situation if I changed the symlink to an Apple alias?

[neverpanic (Clemens Lang)]

You can try; the additional data point would be interesting, even if it doesn't work. Meanwhile, you can disable sandboxing entirely as a temporary workaround by adding sandbox_enable no to your macports.conf. Since sandboxing is a good thing in general, you should remember to change it back once a fix is released.

[dgc.macports@…]

Cc Me!

[dgc.macports@…]

Workaround works for me.

[cooljeanius (Eric Gallager)]

Cc Me!

[cooljeanius (Eric Gallager)]

For me, my case is /opt/local/var/macports/build is a symlink to /opt/local/var/macports/build.build. (I changed this because I read somewhere (perhaps in Fink's docs?) that adding a .build extension to a directory will keep Spotlight from indexing it). Anyways, I'm using the workaround for now...

[larryv (Lawrence Velázquez)]

Has duplicate #39864.

[frozencemetery (Robbie Harwood)]

Cc Me!

[jmroot (Joshua Root)]

I don't think it's unreasonable to require prefix and portdbpath to be fully normalised. Both can be changed at install time.

[neverpanic (Clemens Lang)]

People _do_ create those symlinks after installing MacPorts. Since this is the first feature to break that behavior, I consider it a regression and we should fix it, especially since it probably only takes a few calls to file normalize.

[jwhowse4]

Replying to jmr@…:

I don't think it's unreasonable to require prefix and portdbpath to be fully normalised. Both can be changed at install time.

I am not certain I understand the definition of normalized in this context, but the symlink to /opt existed on my system before any version of macports was installed.

[neverpanic (Clemens Lang)]

Replying to jwhowse4@…:

I am not certain I understand the definition of normalized in this context, but the symlink to /opt existed on my system before any version of macports was installed.

Normalized means the paths in $prefix and $portdbpath should not contain any components that are symlinks or aliases, i.e. he is suggesting you should have configured your MacPorts installation using --prefix=$(readlink /opt)/local.

[larryv (Lawrence Velázquez)]

Has duplicate #39889.

[dgc.macports@…]

Replying to jmr@…:

I don't think it's unreasonable to require prefix and portdbpath to be fully normalised. Both can be changed at install time.

(This may be purely rhetorical, not sure whether it adds anything or not.) I'm new here and I realize this might not carry a lot of weight, but I do think that's unreasonable. Probably the number 1 purpose of symlinks in practice is to give the user or installer some degree of ongoing maneuverability in distancing canonical location from actual. It's not just at install time: what if at install time I intall to /opt/local but at a later time the disk is too full for comfort, and I move it? What if for backup reasons, /opt/local/var is on a distinct disk, while the rest of /opt/local is not? What if I temporarily need to move /opt/local and then move it back when the condition is over? These are reasonable things that people do, but are ruled out by treating the situation as an install-time-only setting. It breaks the premise of symbolic links.

I installed MacPorts probably 3-4 years ago, and have carried it forward using upgrades through three laptops. Changing it at install time isn't that attractive.

(N.B. this wouldn't be an objection if package managers generally differentiated packages I request from packages that are installed as dependency resolutions, allowing me to catalog things I want separate from things I need in this iteration of the packaging ecosystem.)

[neverpanic (Clemens Lang)]

Replying to dgc.macports@…:

(N.B. this wouldn't be an objection if package managers generally differentiated packages I request from packages that are installed as dependency resolutions, allowing me to catalog things I want separate from things I need in this iteration of the packaging ecosystem.)

MacPorts does that since (I think) 2.0. port echo requested, port echo leaves.

[kk1987@…]

Cc Me!

[trolin421]

Cc Me!

[joemirizio@…]

Experiencing this same issue with a subset of ports I was upgrading. Most installed fine, but others failed during the extraction.

Example:

:debug:extract Executing command line:  cd "/opt/local/var/macports/build/_private_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_git-core/git-core/work" && /usr/bin/gzip -dc '/opt/local/var/macports/distfiles/git-core/git-1.8.3.4.tar.gz' | /usr/bin/gnutar --no-same-owner -xf -
:info:extract /usr/bin/gnutar: git-1.8.3.4: Cannot mkdir: Operation not permitted

I am running 10.6 (v2.2.0) and my prefix is not symlinked. After adding sandbox_enable no to my macports.conf, it seemed to work. What does this option do?

[larryv (Lawrence Velázquez)]

Replying to joemirizio@…:

Experiencing this same issue with a subset of ports I was upgrading. Most installed fine, but others failed during the extraction.

Do the ones that work get installed via binary archive?

Example:

:debug:extract Executing command line:  cd "/opt/local/var/macports/build/_private_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_git-core/git-core/work" && /usr/bin/gzip -dc '/opt/local/var/macports/distfiles/git-core/git-1.8.3.4.tar.gz' | /usr/bin/gnutar --no-same-owner -xf -
:info:extract /usr/bin/gnutar: git-1.8.3.4: Cannot mkdir: Operation not permitted

I am running 10.6 (v2.2.0) and my prefix is not symlinked.

Can you describe your setup, then? Why does the build directory in your example start with _private_opt_local?

After adding sandbox_enable no to my macports.conf, it seemed to work. What does this option do?

It does what it says on the tin​.

[joemirizio@…]

Replying to larryv@…:

Do the ones that work get installed via binary archive?

I am not sure how to tell if those upgrades were from a binary archive.

Can you describe your setup, then? Why does the build directory in your example start with _private_opt_local?

Ah, after checking I see that my /opt is actually symlinked to /private/opt (I don't recall doing this manually).

[larryv (Lawrence Velázquez)]

Has duplicate #39941.

[larryv (Lawrence Velázquez)]

Has duplicates #39979 and #39981.

[neverpanic (Clemens Lang)]

Has duplicate #39965.

[tamyrvoll@…]

Cc Me!

[orbeckst (Oliver Beckstein)]

Cc Me!

[elelay (Eric Le Lay)]

Cc Me!

[jmroot (Joshua Root)]

So why isn't editing macports.conf and making portdbpath fully normalised an option again?

[ksee.zelgadis@…]

Cc Me!

[pixilla (Bradley Giesbrecht)]

Cc Me!

[RJVB (René Bertin)]

Replying to jwhowse4@…:

The entire /opt directory is a symlink. This was done in order to place /opt on a different physical disk than the operating system.

Do you think it would resolve the situation if I changed the symlink to an Apple alias?

Almost certainly not, MacPorts works in MacOSX's "Unix" bowels and unless things have changed after 10.6, Apple aliases/shortcuts are different beasts from Unix symbolic links even if the latter show up the same as the former in Finder windows.

Mac OS X has ALWAYS had a habit of resolving symbolic links, look e.g. at shared library dependencies. Annoying, but I presume there are security reasonings behind this.

My /opt/local is a symlink in order to have the MacPorts tree off the boot partition. That started causing troubles not so long ago, but the solution is very easy, esp. since from what I saw the housekeeping apps had always been aware of the true location of the tree. I just changed the prefix and all other variables referring to /opt/local in /opt/local/etc/macports/macports.conf to the tree's true location. That seems to have worked - after all, it's not MacPort's business if I decide to access its tree through an indirection, is it now? :)

[larryv (Lawrence Velázquez)]

Has duplicate #40520.

[larryv (Lawrence Velázquez)]

Has duplicate #40574.

[tamyrvoll@…]

Cc Me!

[trudelle@…]

Cc Me!

[larryv (Lawrence Velázquez)]

Has duplicate #40769.

[andrea.bigagli@…]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Replying to joemirizio@…:

Ah, after checking I see that my /opt is actually symlinked to /private/opt (I don't recall doing this manually).

Ancient ​Cisco VPN installers did this.

[larryv (Lawrence Velázquez)]

Has duplicate #40839.

[larryv (Lawrence Velázquez)]

Has duplicate #41395.

[mg13@…]

Cc Me!

[neverpanic (Clemens Lang)]

I think r113704 fixes this. If you're running MacPorts trunk, please install this change and test.

I will make sure this finds its way into the next release, which will probably be 2.3. If we're going to do another bugfix release (i.e., 2.2.2), I'll make sure to merge this, too.

[neverpanic (Clemens Lang)]

r113704 introduced a test failure (e.g., see ​https://build.macports.org/builders/buildbase-mtln-x86_64/builds/527/steps/test/logs/stdio/text), which is fixed in r113705.

[nerdling (Jeremy Lavergne)]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #42339.

[larryv (Lawrence Velázquez)]

Has duplicate #42455.

[jul_bsd@…]

Cc Me!

[jul_bsd@…]

So, any plan to make a bug release or 2.3 is imminent? it's resolved since 3m but no release. or a way to update to trunk? or not advised? (as said here ​https://lists.macosforge.org/pipermail/macports-dev/2014-February/025888.html)

[ryandesign (Ryan Carsten Schmidt)]

You're welcome to run MacPorts from trunk if you like. Many of the developers do.

MacPorts 2.3 will be released when we feel it's ready and when we get around to it. There is no pre-determined release date.

[RJVB (René Bertin)]

Out of curiosity, what does the sandboxing feature do, other than preventing access if there are symlinks in the prefix?

It's a pity OS X doesn't have mount --bind, but I'm starting to consider rather seriously to move the whole tree to a ZFS dataset that I'd mount on /opt/local. The only thing holding me back is the fact that those do not currently allow SpotLight indexing, something which does come in handy rather frequently to find specific MacPorts files ...

[neverpanic (Clemens Lang)]

The sandbox prevents build (and install) routines from writing stuff outside the places they're supposed to write. MacPorts runs the installation process as root so that installation routines can change ownership of files (granted, we could use something like fakeroot for that – patches welcome). We've had some ports that were not correctly using a staging area to install their files in the past, but write directly to /opt/local. That doesn't give MacPorts any chance to track the files installed, which is why we like to avoid that. With sandboxing, these operations fail as they should.

[keybounce]

How do I tell "sudo port upgrade" that I want to switch to the trunk?

And yes,

keybounceMBP:macports michael$ ls -l /opt
4 lrwxr-xr-x 1 root wheel 21 Apr 15  2012 /opt -> /Volumes/UserData/opt/

I also have "symlink to move off the boot" issues.

(What's the proper way to format short lines without having to make double spacing here?)

[keybounce]

Cc Me!

[keybounce]

Alright, I added the "/Volumes/UserData" to the two paths in macports.conf

Suddenly, "sudo port install <port-name>" is no longer attempting to download precompiled binaries -- it only wants to fetch source, patches, and compile everything.

[neverpanic (Clemens Lang)]

Use WikiFormatting to format Terminal output (e.g. using {{{ and }}}). MacPorts can not automatically switch itself to the trunk version, you need to follow ​http://guide.macports.org/#installing.macports.subversion to do that. That being said, it looks like the 2.3 release will arrive soon-ish.

Please don't modify the value of prefix in macports.conf. It's meant to be strictly read-only (why do we even have it in there anyway?) and is probably what's keeping you from getting the binaries. If I remember correctly having a non-normalized prefix is not what's breaking things, it's the value of portdbpath.

[keybounce]

So with prefix as /opt, and portdbpath as /Volumes/UserData/opt, things work.

I managed to get git-core upgraded. Even p5-error worked.

But GitX failed.

Looking over the logs, it seems that it tripped on the same issue (sandboxing) in a different location:

:info:build error: couldn't create directory /var/folders/jw/gr1qkb8n3hl3b_s9k96j94z40000gq/C/com.apple.Xcode.503/SharedPrecompiledHeaders/AppKit-anlqtgejayacuyboylniebtigjsf: Operation not permitted

keybounceMBP:macports michael$ ls -l /var/folders/
total 8
0 drwxr-xr-x  3 root wheel 102 Jan 23  2013 d0/
0 drwxr-xr-x  3 root wheel 102 Feb 14  2013 dh/
0 drwxr-xr-x 10 root wheel 340 Feb 20  2013 foo/
4 lrwxr-xr-x  1 root wheel  34 Jan 22  2013 jw -> /Volumes/UserData/Apple/Folders/jw/
4 lrwxr-xr-x  1 root wheel  34 Jan 22  2013 s1 -> /Volumes/UserData/Apple/Folders/s1/
0 drwxr-xr-x 18 root wheel 612 Jun 18  2013 zz/
keybounceMBP:macports michael$ ls -ld /var/folders/jw/.
0 drwxr-xr-x 3 root wheel 102 Jan 22  2013 /var/folders/jw/./

Incidentally, my own T folder in there is also moved:

keybounceMBP:macports michael$ pushd $TMPDIR
/var/folders/d0/7h02ky8902xf4866mr_xvkq00000gp/T /opt/local/etc/macports 
keybounceMBP:T michael$ pwd -P
/Volumes/UserData/Users/michael/tmp/T

and I've never had anything complain.

Installing the svn base now ...

[keybounce]

Nope, same thing happens.

How do I add a file (the full log) to an existing ticket?

EDIT: Got it, uploaded.

[keybounce]

GitX fails, tripping on sandboxing and a symlink, even with the 2.2.99 from svn

[neverpanic (Clemens Lang)]

Yeah, the sandbox only does (allow file-write* (regex #"^(/private)?(/var)?/tmp/" #"^(/private)?/var/folders/"). Why is you temp dir a symlink? What kind of setup causes this? What is /Volumes/UserData?

[keybounce]

This system dates from 10.6. During setup, I did reasonable "best practices".

I made the root partition big enough for the operating system, and reasonable growth. Anything from apple would go on the root; anything of my own (user data) would go onto a UserData partition.

Symlinks made it seamless.

Swapfiles? /tmp? Second partition. Minimize writes to the root.

Developer tools in the root? Symlink.

Then, comes 10.7.

Now, launchD won't even boot the system unless several things are valid directories before mounting any other partitions -- so suddenly swap, /var/folders, etc, have to be on the root. Worse, developer tools won't update across a symlink.

So, my root partition went from being roomy to crowded -- and I've had to push stuff into the other partition whereever I can.

Finding that some of the Apple frameworks force writes into the personal T directory? Big surprise. I discovered this when a third party screen recorder was running out of disk space, even though I had lots of room on UserData. Investigation found that personal T directory setup -- and the company said that they were using a standard apple framework. At that point, I moved my T -- and the Apple /var/folders directories were large enough that moving them made more room. I was still running out of swap space for a while.

So the bottom line? I made a boot partition the right size for an operating system, but the operating system changed and wants stuff on root that has no business being on root, and insisted that the standard unix system of symlinks was not good enough. I've had to make room.

No, for some reason that I have never understood, disk utility won't let me resize my root partition, even if I boot from the recovery partition.

[neverpanic (Clemens Lang)]

OK, so this is not a corporate default setup or something, but just a custom thing. In that case I'm inclined to say

• provide a patch, or
• disable sandboxing in macports.conf as mentioned in comment:9.

It doesn't really matter whether I agree on whether the OS shouldn't try putting that much stuff on root, since that's Apple's decision and should be filed with them.

AFAIK disk utility will refuse to resize if the partition contains errors, try running verify.

[keybounce]

Fair enough. Can you please tell me where I can actually get documentation on the sandbox system and how to use/configure it, and can you tell me where/how MacPorts interacts with it?

"man sandbox" doesn't really say anything, nor does sandbox-init, sandboxd, sandbox-exec, etc.

EDIT: Disk passes fsck and disk utility verify, no problems.

[neverpanic (Clemens Lang)]

Unfortunately there's close to no documentation on this from Apple at all. I assume it is considered a private API by Apple. There is a little community-generated documentation that was (I assume) used while implementing this feature for MacPorts:

• ​http://reverse.put.as/2011/09/14/apple-sandbox-guide-v1-0/
• ​http://ilostmynotes.blogspot.de/2011/11/howto-write-os-x-seatbelt-sandbox.html
• the scripts in /usr/share/sandbox/.

The implementation in MacPorts is mostly in

• browser:trunk/base/src/port1.0/portsandbox.tcl​, which sets up the sandbox profile string and
• browser:trunk/base/src/pexlib1.0/system.c, which prepends every command to be executed by a Portfile with sandbox-exec -p $profilestring.

[cooljeanius (Eric Gallager)]

Replying to keybounce@…:

Fair enough. Can you please tell me where I can actually get documentation on the sandbox system and how to use/configure it, and can you tell me where/how MacPorts interacts with it?

As far as its history in MacPorts, this thread from the macports-dev mailing list probably best documents the development of the sandboxing feature in MacPorts:

• starting with where jkh changed the subject line: ​http://thread.gmane.org/gmane.os.apple.macports.devel/20116/focus=20221
• the actual start of the thread: ​http://thread.gmane.org/gmane.os.apple.macports.devel/20116

Also, on a more general note, I have a fork of a repo with some sandbox profiles in it on GitHub:
​https://github.com/cooljeanius/OSX-Sandbox--Seatbelt--Profiles

[keybounce]

Oh wow ...

First: There's a much better sample set of profiles: /System/Library/Sandbox/Profiles

Second: What kind of scheme is apple plotting?

(define (legacy-entitlement ls)
  (let loop ((ls ls))
    (if (null? ls) #f
        (let ((entry (assoc (car ls) *entitlements*)))
          (if entry (cdr entry)
              (loop (cdr ls)))))))

(Is it full lisp/scheme? What dialect? Does this mean that any time a program attempts to run, a different program is run before it to modify its execution environment? Can you just imagine the infection vector this can provide?)

Third: sandbox-simplify: That command is not referenced from sandbox, sandboxd, sandbox-exec, etc -- yet it speaks volumes.

Fourth: It looks like making symbolic links work is as simple as mentioning it in a

(allow file-read-metadata
       (literal "/etc")
       (literal "/tmp")
...

block.

Fifth: I wonder if it's possible to make a system-specific version of system.sb or application.sb (normally in that /System directory) and solve all of these issues, even for Apple software updates ... (would be wonderful for getting stuff that does not belong on root off of it.)

[neverpanic (Clemens Lang)]

Replying to keybounce@…:

(Is it full lisp/scheme? What dialect?

I don't know. Find out by trying, I guess?

Does this mean that any time a program attempts to run, a different program is run before it to modify its execution environment?

No, not in the general case. If you want a sandbox you'll have to apply it manually by running sandbox-exec -p $profile – there's no automatism here. In the case of MacPorts, yes, the sandbox profile string is parsed by sandbox-exec each time a MacPorts port executes a command. But, Portfiles can already execute arbitrary code, so I don't see how that is less secure than what we already have. This is not meant as a security device in MacPorts, but as a way to prevent installation routines from doing stuff we don't want them to.

Can you just imagine the infection vector this can provide?)

Why would you give a user permission to edit sandbox profiles used by privilege levels he doesn't have?

Third: sandbox-simplify: That command is not referenced from sandbox, sandboxd, sandbox-exec, etc -- yet it speaks volumes.

If you mean "it speaks volumes" by its name and because you think simplifying a sandbox definition is bad per se, I think you're wrong. This command is intended to produce a first draft of a sandbox definition for software $x after getting a trace of its behavior in a controlled environment. Say you want to set up a sandbox for a GUI tool, so you run it with tracing enabled, do some (hopefully representative) stuff with it, close it and take a look at the trace output. sandbox-simplify is supposed to turn this into a more generic and more useful profile (because otherwise you might end up with a sandbox that only allows users to open the file you used while tracing, but not any other file). The command is a tool for developers to get started with sandboxing, it is not meant to replace the work of a developer to verify the rules are sane and needed.

Fourth: It looks like making symbolic links work is as simple as mentioning it in a

(allow file-read-metadata
       (literal "/etc")
       (literal "/tmp")
...

block.

Yes, but that only means you can read where the symlinks point. Opening a file after following the symlink (e.g. in /private/etc) will still be denied.

Fifth: I wonder if it's possible to make a system-specific version of system.sb or application.sb (normally in that /System directory) and solve all of these issues, even for Apple software updates ... (would be wonderful for getting stuff that does not belong on root off of it.)

That's out of the scope of MacPorts, but I think it would just cause failures rather than getting anything moved.