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.

  • 1
    But [[ -w /etc/passwd ]] && echo "yes" return yes for the root user under both High Sierra and Mojave. – David Anderson Dec 31 '18 at 1:00
  • @David Anderson, your test only returns "yes" on High Sierra when I do it. Doesn't return anything on my Mojave system (in both cases being run by root). – Marnix A. van Ammers Dec 31 '18 at 1:11
  • @MarnixA.vanAmmers It returns yes for me on Mojave, with running previously sudo -i or sudo bash – Yoric Dec 31 '18 at 1:20
  • It still failed for me, but when I turned off SIP, it succeeded. Does 'csrutil status' say disabled on your systems? – Marnix A. van Ammers Dec 31 '18 at 19:23
  • Works for me as expected with SIP enabled: whoami; [[ -w /etc/passwd ]] && echo "yes" leads to root yes – nohillside Dec 31 '18 at 21:40
2

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.

  • /etc/passwd is not protected by SIP, run ls -O /etc/passwd to check. – nohillside Dec 31 '18 at 21:42
  • 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 1 at 4: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 1 at 4:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .