Hacker News Reader

Comment by Wowfunhappy | Hacker News Reader

> Read-only state of the system volume can be disabled but not persistently, will revert to read-only after a reboot

Wait, what? Even with SIP off?

Can it be disabled from within the OS? Can I add "command-to-make-system-rw" to a launchd plist that runs at load on my machine?

View on HN

I think having persistent access is the file system equivalent of logging in and working entirely from root.

The default should be a restricted system, with intentional, temporary, jumps into unrestricted access for making whatever infrequent system configuration changes.

What’s the use case for constant RW access? What changes at this level so frequently?

> I think having persistent access is the file system equivalent of logging in and working entirely from root.

Except that those system files are already protected behind root privileges, so they're only read-write if I have root. And, one reason the root privilege system works is because temporarily gaining root when necessary isn't painful.

I indeed don't change root files on a daily basis, but when I do, I don't want to have to go through an extended rigamarole every single time. Typing in my password should be enough.

I totally respect that Apple wants to keep normal users out of this stuff. I just want a way to remove the safety wheels one time, instead of again and again.

I've shot myself in the foot enough to appreciate an ever-lengthening list of hurdles I need to jump to do so again. I would be protesting if there were no way to make the rootfs read-write, but as it is I'm happy with having to perform a command or two when I want to write.

I suspect you can do that in a launchd script, but however much more involved it is than typing my password, I'm probably fine with leaving it as-is.

Disabling SIP, at least from Apple's POV does most of what you want. They've also implored people to be good UNIX citizens and make liberal use of /usr/local, which they explicitly give you - the user of the hardware - ownership of.

> They've also implored people to be good UNIX citizens and make liberal use of /usr/local, which they explicitly give you - the user of the hardware - ownership of.

/usr/local is root:wheel by default. macOS provides it to you as a place to put your software, but it not give your user ownership of this directory.

> but it not give your user ownership of this directory.

Admin users can sudo, sudo should be used to install software. Your thinking is the shenanigans that Brew does, making `/usr/local/whatever` writable by anyone, without a password.

This is not how smart people install software.

Edit: wow what a typo. One character completely reversed the intend meaning of the last sentence.

> This is now how smart people install software.

On the contrary, I think what Homebrew does with regards to permissions is fundamentally incorrect. /usr/local, being shared, should be owned by root, and it should require administrator permissions to install software there.

Gah, sorry typo in my comment, it should say "not", but it says "now.

Anyway, I agree, it should be root owned and use sudo/similar to install.

Sorry for the confusion!

If I shared my Mac with anyone I’d agree, but as it is, my Mac is a single-user machine and I’d rather run brew as myuser:mygroup to avoid running the install scripts as root.

With Brew it's a moot point - you can't choose to do otherwise, it will refuse to run as root, and has no capability to do the "normal" `make && sudo make install` pair, where you build as user and install as root.

I'd rather not run a random `make install` (or, in Brew's case, as random ruby script) as root, though.

And that's what a user ~/bin directory is for then - you don't want to run as root, install in your home.

Installing user-own software, in a user-specific location is fine.

/usr/local is not user specific, and setting the permissions so it is treated that way doesn't stop other software referring to it as a system-wide $PATH.

There is no ~/bin directory on macOS though. Homebrew could create one, but iirc Apple's guidelines discourage creating new directories in the user's home folder. (Which I generally agree is a bad practice, btw, although this might be an exception.)

I guess you could put something in the ~/Library folder, although that's not ideal either...

There's no `/usr/local/Brew` (or whatever directory it uses) either, but it creates it, and it changes the ownership of `/usr/local/bin` to make it writable without a sudo prompt - which is more egregious than creating a `~/bin` directory, any day of the week.

If they didn't insist on using `/usr/local/bin` (which is in the default $PATH) the permissions issue would be much less of an issue IMO (not a non-issue, but less of an issue than it is currently)

I happily make /usr/local owned by myuser:mygroup—on a single-user machine that’s no more dangerous than putting ~/bin into $PATH

If you edit your own $PATH, it literally only affects your user account.

`/usr/local/bin` is in the default $PATH, so making it world writable means anything malicious installed there may end up being called by a system utility that runs as another user than your own.

For your (and Brew's stated goal), installing into ~/bin would be a better result, because it's literally that single users account.

But the Brew developers never want to hear any criticism of their ridiculous bullshit, whether it's security issues or their half-assed dependency resolution.

I should have been clearer about this^

On most systems with 1 user it's irrelevant as by default they are in the admin group. Rather, usr/local exists and you may read and write into it even if you don't have explicit ownership (e.g, root). Whether that's brew, or your own script doesn't really matter.

On Mojave at least, `/usr/local` is owned by root:wheel, the first user account (which has admin rights) is not in the wheel group but can use sudo to write to `/usr/local`.

rw file access doesn't mean there's a lack of file level permissions restricting a non sudo user from accessing an otherwise restricted file. case in point: try editing the /etc/hosts file without sudo. you can't save (without invoking sudo from within vim).

ro means no matter what I try, that file is ro unless the fs is remounted rw. Again, it doesn't negate file system level user/group permissions. and remounting a system level partition rw isn't something I'd do on a whim.

I like the idea of a ro partition for system level OS files, personally, but without user level access somehow - it's not something to be looked forward to.

> I like the idea of a ro partition for system level OS files, personally, but without user level access somehow - it's not something to be looked forward to.

Apple is clearly stating that the user will have access, so I'm not concerned on that front.

What bothers me is the "will revert to read-only after a reboot" part, which seems unnecessarily punitive. It's like Apple is saying "We're going to let you do this thing, but we don't like it, so we're going to make you redo it every single time to remind you of our disdain."

Elsewhere in this thread, Pwinnski said he likes having an extra, persistent safety check. I think that's great. But, an extra command line flag to make the setting persistent really shouldn't be too much to ask for.

If my launchd idea works in practice, this is all moot, and I retract all my complaints. I'm just nervous.

How often do you need to touch the system partition in the first place? Is this something you need to do every boot?

From the video, you can only enable read/write if you disable SIP in the first place. They didn't answer say anything about the second question.

Reply on news.ycombinator.com