How come I cannot view /Users/foo/ from a second admin user, but I CAN view them from macOS on another partition?

Question

I've been trying to get a clean macOS.

First effort was to create a second admin user. I found that userB couldn't see /Users/userA/*.

Second effort was to create a second APFS partition, and install macOS onto it (from userA).

Now my machine boots into macOS_new, and surprisingly I'm able to view /Users/userA/* on macOS_orig.

Suppose I had somehow created this new APFS partition and installed macOS from outside of userA... would userA's files still be visible to me? If so that's a huge security hole, surely! So I'll assume not.

If not, then what's the magic that allows macOS_new to view macOS_orig/userA's files?

Original macOS:

> ls -lde /Volumes/πTB/Users/pi/
drwxr-xr-x+ 111 pi  staff  3552  1 Dec 10:52 /Volumes/πTB/Users/pi/
 0: group:everyone deny delete
> ls -ldne /Volumes/πTB/Users/pi/
drwxr-xr-x+ 111 501  20  3552  1 Dec 10:52 /Volumes/πTB/Users/pi/
 0: ABCDEFAB-CDEF-ABCD-EFAB-CDEF0000000C deny delete

New macOS:

> ls -lde /Users/pi/
drwxr-x---+ 21 pi  staff  672  1 Dec 15:17 /Users/pi/
 0: group:everyone deny delete
> ls -ldne /Users/pi/
drwxr-x---+ 21 501  20  672  1 Dec 15:17 /Users/pi/
 0: ABCDEFAB-CDEF-ABCD-EFAB-CDEF0000000C deny delete

Answer 1

You write:

Suppose I had somehow created this new APFS partition and installed macOS from outside of userA... would userA's files still be visible to me?

And the answer is yes, they would be visible to you - assuming that the original is not encrypted with a key not available to you when booting into the other macOS installation.

If so that's a huge security hole, surely!

The answer to that is no, that's not actually a huge security hole. That's how file systems work on any operating system on any computer.

If you do not encrypt the data, it is available to read when you have physical access to it.

In very basic terms, the macOS operating system does limit what non-administrative users can do - this includes reading files that do not belong to themselves. This is handled by adding ownership information to each file stored on the file system, and comparing it to the current user when a file read is requested.

On many operating systems, user ownership is stored not by user names, but rather by user ids. The user id is typically a number assigned when the user is created. On macOS the first user created is typically assigned the number 501, the second user the number 502, and so on.

When you mount the file system created by the old macOS installation on your new macOS installation, the operating system will attempt to impose the same restrictions. However, the file ownership of for example "501" might now mean an entirely different user, or it might, as in your case, happen to be a user named the same thing. That's entirely up to the order in which you have created the users.

This is all very "non-surprising", and does not in any manner indicate that there is a security hole in the OS, a bug or anything like that. This is how file systems has worked for decades across many different operating systems.

If you want to stop this, you'll want to encrypt your data.

Note: You can "skip" the imposed restrictions simply by accessing the files with a superuser (an admin user). Using the Terminal, you might try to view the contents of a file like this:

less /Volumes/πTB/Users/pi/secret.txt

and be denied access to the file because of the file ownership and permissions. However, if logged in as an user with Admin rights, you can simply add on sudo to the command, like this:

sudo less /Volumes/πTB/Users/pi/secret.txt

You would then be prompted for your (own) password, and then be able to read the file. You do not need the password of that "other user" in order to read the file.