1

An old bash script I have tested to see if a user was root by seeing if /etc/passwd was writeable. In MacOS High Sierra it returned true for root, and false for anyone else. But in macOS Mojave the test returns false even for root.

If I run that test [ -w File ] on other files with the same permissions and ownership, such as /etc/hosts , it correctly returns true for root and false for anyone else in both Mojave and High Sierra. I see no special file flags or extended attributes on /etc/passwd.

The script is no problem to fix, but I'd like to know how/why this test is different on that file vs other files and why this is in Mojave only. If this has to do with SIP, then I'd like to know how one can test to see if a file or directory is somehow protected by SIP.

Update: I found that disabling SIP made things work as expected, that is, for a root user the bash test "-w /etc/passwd" would be true. Enabled SIP again and all is working as expected. I don't know if I should delete this question, or leave it just in case someone runs into a similar problem. Doing an "ls -O /etc/passwd" does not show the file as restricted.

Marnix A. van Ammers
  • 1,573

1 Answers1

3

Checking to see if a file is "writable" as a way to determine if a user is root is a bad way to check permissions. For instance....

  • you can add a user to a group (i.e. wheel) that has write permissions to a file that's normally owned by root

  • a file can be flagged to not have write permissions even by root even though you have root access.

  • a file may have had its permissions changed to "non-writable" by root (intentionally or not)

  • SIP, or System Integrity Protection (as you've already discovered) will prevent even the root user from writing to system files.

Check for the User ID

Instead, you should look at the UID of a particular user with the function id

$ id -u

A root user, will have an ID of 0.

To see how you can use this in a script to check for root privileges, see the answer in the post Running a Script with Administrator Privileges.

Checking SIP

This is actually pretty easy....

$ csrutil status

However, if it is enabled, you will have to boot to Recovery Mode to disable SIP. This isn't something you can do on the command line (or from a script) in a normal session. It is much easier to simply test for the UID as described above.

Community
  • 1
Allan
  • 101,432
  • /etc/passwd is not protected by SIP, run ls -O /etc/passwd to check. – nohillside Dec 31 '18 at 21:42
  • 1
    I'm actually aware of all of the above. I was only trying to find an explanation for why the test "-w /etc/passwd" is false in my Mojave when I have SIP enabled and true when I have SIP disabled and why this did not hold true for other Mojave installations. Crazy thing is, this just came clear. A reboot didn't do it. Disabling and re-enabling SIP didn't do it. Somehow it is clear now and everything works as expected. – Marnix A. van Ammers Jan 01 '19 at 04:08
  • Re-enabling SIP might have done it. I didn't immediately notice that the problem came clear. Only some hours later did I notice. Maybe I'm going crazy. I've updated my question. – Marnix A. van Ammers Jan 01 '19 at 04:35
  • I'm baffled at why a relatively simple test (checking if the UID is 0) ought to be 'replaced' by a much more complicated test for permissions on /etc/passwd...? Under which special scenario would checking for write permissions on /etc/passwd be advantageous? Also … what if in the future other users get write permissions on that file as well (for whatever reason)? Checking for UID seems to be much better & future-proof — not even Apple would change the UID of root! – Gwyneth Llewelyn Feb 24 '23 at 21:12
  • 1
    @GwynethLlewelyn - my guess is this was what ended up being an XY problem for the user. – Allan Feb 24 '23 at 21:20
  • @Allan most definitely, since otherwise none of that makes any sense :-) – Gwyneth Llewelyn Feb 26 '23 at 00:11