Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
MacOS Catalina has a dedicated system volume now
- Thread starter STOCK411
- Start date
- Sort by reaction score
It still mounts as writable if booted into a different OS, but this is going to be a huge hassle for system theming, etc. if simply disabling SIP isn't enough to always make it mount as writable.
Those of us who choose to disable SIP have valid reasons for doing so. Hopefully Apple will resolve this issue in a future update.
Anyone needing (or just wanting!) write access, log a succinct Feedback request explaining why you need to write to that volume. The more requests they get, the more likely they'll consider adding some kind of toggle to make it writeable.
You need to remount it as writeable. Check the Apple WWDC video.
[doublepost=1560846770][/doublepost]
What is your use case that you need write access to system files?
[doublepost=1560846923][/doublepost]
The went through quite some trouble to split the partitions, I don’t really see them reversing course on this just because some people feel uncomfortable not being able to overwrite system files. Also, there is already a toggle. It’s not persistent though, it has to be specified anew on every boot.
Change certain system settings that are unavailable as part of settings in macOS. For example, display hidden and system files.
Also, could you give the WWDC video link to us so we can watch it ourselves? Thanks.
I'd forgotten about that, despite the fact I actually posted about it earlier in this thread!
https://developer.apple.com/videos/play/wwdc2019/710/
I don’t quite follow. Isn’t that setting part of the standard configuration database? And even if you need to configure something that is not available via a plist you can still write to /etc and so on. The write-only protection affects things like kernel, /bin and so on. Why you would need to write to these?
Thanks.I'd forgotten about that, despite the fact I actually posted about it earlier in this thread!
https://developer.apple.com/videos/play/wwdc2019/710/
[doublepost=1560857870][/doublepost]
Ok. I am lost and will stop here. But having the ability to modify system files is not necessarily a bad thing, as long as the user know what they are doing, and average people do not know how to modify it.
Haven't seen the video, but the following command seemed to work:
Code:
sudo mount -t apfs -wu /dev/disk1s5 /Volumes[doublepost=1560876925][/doublepost]Thanks, going to quote this here. Definitely a bit cleaner than my command, but either one works.
[doublepost=1560877401][/doublepost]One-line solution that works once logged in (with SIP disabled):
Code:
sudo mount -wu /; killall Finder
Last edited:
so what needed to be done if i want to remove some services from system/Library/LaunchAgents or demons ?
for example com.apple.familycircled.plist ???
for example com.apple.familycircled.plist ???
I suppose you just disable them from running. Not sure that this folder is even write-protected...
[doublepost=1560899544][/doublepost]
The problem with modifying system files is that it’s only useful if you want to hack the OS in some way (e.g. replace core system utilities or drivers). I’ve been administering Macs and Linux machines for a while but I never came across such a use case on a client machine. On the other hand, a malicious software could modify these files to infect or exploit your machine. So yeah, i really don’t see why this stuff should be user-writeable, admin privileges or not.
Playing the devil's advocate... isn't it the other way around? Classic Mac OS had, IIRC, a locked down system, and it was hard to modify system files. I'd think this would make macOS more secure like Mac OS 9 and beneath was -- more secure, protected from viruses and hackers. In other words, going back to the legacy days of the Macintosh, but modern and protected. IIRC, up to Tiger, Mac OS X was easier to exploit due to the open Unix structure. I think it was around Leopard and/or Snow Leopard when Apple finally tightened the system code to make it harder to exploit/modify.
Or am I remembering wrong?
This is the best move since they decided to support 64 bit and a return to form for them. OS9 and below didn't allow this kind of nonsense either and it shouldn't have ever been loosened up to placate luring PC users. If you watch the WWDC videos and get to developer and read the docs, this is Federighi taking the OS - ALL OF THEM back to their nextstep roots and getting serious about security/performance and what's good for the ecosystem. Not Pandering to the white/gray/black hat communities. Best example is this meltdown/spectre thing. This makes it completely irrelevant because even if you can hack the in process cpu functions, it doesn't matter - zero persistence. Reboot done. The walled garden argument falls flat too, Get an android or PC if you want to run something that you can't with any certainty it isn't going to damage or corrupt your system integrity or security - end of argument goes there.
I blame this on the PC converts who want their Windows attributes and be damned if it drags the ecosystem through the dirt to have it. I work primarily in Unix and A/UX and that's not for everyone and that's okay. MacOS is not going to be for everyone for the same reasons OS9 etc/Linux etc/OS2 and every other system isn't for everyone either. To be fair, this isn't a Windows slam but it is a common sense point to consider. There is zero reason to complain or argue for any change to closing the system volume from attacks. Make your vendors provide support or vote with your wallets when they don't by providing the kexts you need - no one was punishing SUNN or IBM for doing the right thing in the 90's, or better still - join apple developer and write your own and get them approved and notarized. Problem solves itself but it won't be a hacked solution and one that everyone can access and benefit from.
I blame this on the PC converts who want their Windows attributes and be damned if it drags the ecosystem through the dirt to have it. I work primarily in Unix and A/UX and that's not for everyone and that's okay. MacOS is not going to be for everyone for the same reasons OS9 etc/Linux etc/OS2 and every other system isn't for everyone either. To be fair, this isn't a Windows slam but it is a common sense point to consider. There is zero reason to complain or argue for any change to closing the system volume from attacks. Make your vendors provide support or vote with your wallets when they don't by providing the kexts you need - no one was punishing SUNN or IBM for doing the right thing in the 90's, or better still - join apple developer and write your own and get them approved and notarized. Problem solves itself but it won't be a hacked solution and one that everyone can access and benefit from.
Last edited:
May I ask how do you manage to reinstall Catalina. I was stuck on the 9000F error.
The system files are write-protected at the kernel level. The System Integrity Protection feature has been accomplishing this since El Capitan.
You might want to look into that, only certain files are protected by SIP since El Capitan by a maintained master list, the host directories are not. Some argue that equals the same thing - but for anyone who has done posix traversal - it is not.
This new iteration is the function it should have always been.
This new iteration is the function it should have always been.
I have upgraded to catalina beta from Mojave and my apfs system is still writable flagged on main and data container..
I don't know if it was an installer "error" or what..
Last edited:
You should be fine, they said at WWDC the lockdown would be in later DP's. I wouldn't look for that until the public beta 1 or 2
According to Apple’s own support document, when SIP is turned on the entire system folder is locked along with some other folders as well.
[doublepost=1560926257][/doublepost]It does mention that signed Apple processes can get around this lock, which means the potential for exploits that overwrite system files using these processes or a low-level kernel exploit is theoretically still there. The same would have to be true in Catalina with the read-only system partition, otherwise system updates that require write access would be impossible.
Last edited:
I know this is going to sound silly to all you macOS geniuses out there, but I like to customise my system icons and wrap the originals in an iOS-like shape so that they have a uniform appearance when placed on the Dock or viewed in LaunchPad. Since I was no longer able to do this even with SIP disabled, I'll give that Terminal command a try to remount the system volume with read/write access. Thanks so much for the tip and I just wanted to say I'm very grateful for all the expert advice given here!
Cheers
Edit: The command worked! I received the following error message in Terminal, but was still able to modify system application icons or replace them outright.
Failed to stat file //AppleInternal, error No such file or directory
Thanks!
Last edited:
Apple engineers surely can work into this and make system update operation better protected.
You are correct about the document but it's a very similar case to apfs raid support in Mojave, according to the raid document there are no caveats to creating software raid volumes for apfs in Mojave using only disk utility, and you CAN and you can read/write to them but not without the expense of disk utility becoming incapable of several routine functions (dmg creation, reliable error inspection correction and even unreliable formatting of raid or other external volumes) SIP, despite what the doc lays out is file level only and only to master list items, otherwise there would be no possibility to clear caches, etc manually at all from El Capitan onward outside of a safe boot scenario - and that will be the future according to one of the engineers at wdc this year -THAT prospect is terrifying to me. I went specifically to get information on how raid will be addressed if at all in future iterations given the state of its support (no updated driver since 2009/being dropped in Yosemite then reinstated in El Capitan and on. More importantly if it was being dropped for some super solution in the Mac Pro for a super solution in hardware. I got the answer to both questions. I wasn't thrilled with either answer.
System updates are trivial even in a locked system volume, But the mechanism will be controlled by the system itself and the engineers who compile it. The issues you bring up are valid but from the looks of DP2, they are relying on the vm for that and that's a good thing because it can exist either in disk or memory state. So a performance gain can be had there as well. There is no locked box that can't be pried open to break it but this is a great step forward to make it harder and eliminate a segment of security issues that been haunting the Mac since the conversion to intel back in 2006.
[doublepost=1560945694][/doublepost]
Glad you found a workaround to it. You can also do it through NSfile commands as a replace command for the apple resources container but I would check it repeatedly through the DP process because I'm not sure if it will be persistent after a point. It should be if they are apps on the secondary volume and not system volume but I would check after each new DP anyway