In a MacOS Mojave bash script "-w /etc/passwd" is false even for root 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.
Checking to see if a file is &quot;writable&quot; 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 &quot;non-writable&quot; 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.