| |
| |
On 3/4/21 8:10 AM, Manolo wrote:
I'm guessing Fink and other tools that use /opt will
get what they want using
/etc/synthetic.conf, which is apple's workaround to
making / read-only.
I'm not aware of this /etc/synthetic.conf file and its
function.
There's no such file here neither in my Intel nor my M1
macOS machines (macOS 11.2.2)
Like /etc/exports, the file doesn't exist until you create
it.
Check out 'man synthetic.conf' for details.
There's no /usr/local/opt nor /System/Volumes/Data/opt
here either.
/System/Volumes/Data/
is where apple wants you to put stuff that would
normally go into the root. It's a writeable directory.
/usr/local/opt and/or /System/Volumes/Data/opt wouldn't exist
until created
by a user or tool.
/usr/local/opt
is apparently a common place for brew to put /opt stuff
so it isn't in the root dir.
Big Sur and Catalina made
large changes to the OS to enhance security,
enforcing
intergrity with cryptographically signed features.
Regular unix folks may be confused by all this (and other stuff
Apple has done).
While I agree with their goal of increasing security, it's ugly
and feels hacky as
to how they've gone about it.
/etc/synthetic.conf tells the OS on boot to create empty
dirs and/or special kinds of
symbolic links to another place. This is apparently is
Apple's workaround to making
root completely unwriteable. With this approach,
apparently Apple can supervise
(and deny) what can be done in the root dir.
My understanding, which must be partial, is different.
macOS now uses 2 "intertwined
filesystems" (my wording for this concept), one holding the
system and one for user files.
That for the system is readonly.
It's readonly in a strong sense: even root cannot write to
it or mount it rw.
Yes; mounting root readonly has always been a design goal of
unix, but it's often
not found implemented.
Given the extreme security climate these days with state
sponsored hacking,
OS vendors have had to start cracking down. Can't blame them.
It used to be possible to bypass that:
mount the system disk on another, earlier, macOS machines
and you can write to /
then reboot and you had your /xxx folder. I did that for
/sw to get my fink.
But then fink was improved to use /opt/sw and /opt is not
in the system filesystem
but in the user filesystem. So root can write to it.
I think in Catalina you could boot into Recovery mode, go into
the Terminal,
and manipulate the root volume of the boot drive, which is
usually mounted rw
as /Volumes/Xxx. (Since the root directory in recovery mode is
the recovery OS,
not the regular boot OS)
However, in Big Sur, for sure if you try to create subdirs on
the bootable root
volume, your changes are REMOVED on boot. They just disappear.
The OS is /really/ enforcing integrity of the OS, not only
read-only,
but insisits on no modification (see above link regarding
crypto-signed features)
That those filesystems are interwined is visible with /opt
which is a top-level directory
but in the writable part. It's also visible when you
install an app, say Firefox, in /Applications:
there you have some files of /Applications in the readonly
filesystem, and others in the writable filesystem.
Ya, notice OS applications are now in /System/Applications,
and /Applications is empty.
That scared the crap outta me one day.. I thought I'd been
hacked.
With macOS 11, it's much worse: the system part of the file
system is cryptographically signed,
so it's impossible to change anything in it, unless you
recreate the signature, with obscure
and not well documented means.
Yes, exactly.
My understanding is also that Apple intends to leave /opt a
part of the filesystem that users
are free to colonize. That's visible with XQuartz,
Macports, Fink that are all put there.
But this may of course change at some future time.
Well, as long as they leave some kind of workaround.
I'm not sure if apple intends to leave /opt specifically, but
rather "provide a workaround
to create empty dirs and/or symlinks in the root directory" that
are up to the user to name.
And as long as the names don't conflict with Apple's design,
they'll be 'allowed' to be created.
Or at least that is the impression I've gotten. I've not
actually dug down deep into
Apple's documentation on the changes.. but it seems clear that's
the intention.
--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/7ef1d960-b071-92f8-16c8-0f70d6a06aca%40seriss.com.
[ Direct Link to Message ] | |
|
| |
