MacOS – In a MacOS Mojave bash script “-w /etc/passwd” is false even for root

bashmacosmojavepermissionsip

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.

Best Answer

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.

Related Solutions

MacOS – Run AppleScript from bash script

The argument for osascript -e can contain newlines:

osascript -e 'set x to "a"
say x'

You can also specify multiple -e arguments:

osascript -e 'set x to "a"' -e 'say x'

Or if you use a heredoc, bash interprets three characters (\, $, and `) between <<END and END but no characters between <<'END' and END.

osascript <<'END'
set x to "a"
say x
END

Edit:

Since osascript can operate with a heredoc (ie take input from /dev/stdin) then one can just write the script as a whole file and prepend with the correct shebang line:

#!/usr/bin/env osascript

set x to "a"
say x

This also allows you to save your apple script as a actual program in ~/Applications/.app using the following procedure (changing for your script's name):

mkdir -p ~/Applications/<APP_NAME>.app/Contents/MacOS
touch ~/Applications/<APP_NAME>.app/Contents/MacOS/<APP_NAME>
open -A TextEdit ~/Applications/<APP_NAME>.app/Contents/MacOS/<APP_NAME>

Ensure that both the script file in .../MacOS/ and the matches

MacOS – Bash Script which calls osascript stops working when run by launchd

Graphical User Session Required

The error occurs because the commands in your osascript require a graphical user session. AppleScript requires a graphical user session to work.

The launchd job is running as the root user in a non-graphical user session.

Alternative Approach

In these situations, the typical approach is to split daemons in two parts – one computer wide and another within each graphical user session. A pipe or socket is frequently used to communicate.

Even as root user, there are barriers that can not be crossed in macOS.