Execute extension attribute and policy scripts as logged in user

[Lapin]

This one has me stumped. In the past when I've needed to run a bash script as the logged in end user I've simply used something along the lines of:

userName=$(stat -f %Su /dev/console)

sudo -u $userName -H bash -c "jamf recon"

This method seems to still work just fine IF I manually call the policy (jamf -policy) or manually initiate an inventory update (jamf recon) but when it's called with the recurring policy action or daily recurring inventory action it fails, and seems to run as root. So:

• Logged in as sjobs, run 'jamf -policy' = Success, policy executes, relevant lines will successfully run as sjobs
• Logged in as sjobs, run 'jamf recon' = Success, EA executes, relevant lines will successfully run as sjobs
• Logged in as sjobs, Mac is not asleep or unattended, recurring policy trigger occurs in background = Failure, policy executes, relevant lines run as root
• Logged in as sjobs, Mac is not asleep or unattended, recurring inventory trigger occurs in background = Failure, EA executes, relevant lines run as root

Where is the difference in how the script interprets when called via triggers instead of manually via terminal? At first I thought it was a Ventura issue but Big Sur and Monterey behave the same way.

[sdagley]

@Lapin Using stat to determine the logged in user from the console is not a reliable mechanism. Take a look at https://scriptingosx.com/2020/08/running-a-command-as-another-user/ for an example of a more reliable mechanism for running a command as the logged in user.

[Lapin]

Thanks @sdagley, I tried switching up the method to determine the logged in user but it hasn't had any effect. Manually running the policy and extension attribute works without issue but when either action runs on their own in the background it executes as root. I included a simple 'echo $user' line in the policy script, when it runs in the background that line still prints out 'sjobs' even though the rest of the user centric commands run as root. So it seems like it's pulling the logged in user without issue, but the sudo (I've also tried using su) commands to run in the user context aren't working properly.

[Lapin]

Example output from manually executing the policy (running sudo jamf -policy from the Mac):

Executing Policy Weekly Mac App Store Updates
Running script Weekly MAS...
Script exit code: 0
Script result: sjobs
-----------------

Mac App Store Applications:
1295203466 Microsoft Remote Desktop (10.8.0) 1333542190 1Password 7 (7.9.6) 682658836 GarageBand (10.4.7) 408981434 iMovie (10.3.5) 409201541 Pages (12.2.1) 409183694 Keynote (12.2.1) 409203825 Numbers (12.2.1) 

----------------
----------------

No available Mac App Store updates 

----------------

And an example of the same output when the policy ran on it's own via the recurring policy trigger 15 minutes later:

Executing Policy Weekly Mac App Store Updates
Running script Weekly MAS...
Script exit code: 0
Script result: sjobs
-----------------

Mac App Store Applications:
No installed apps found 

----------------
----------------

No available Mac App Store updates 

----------------

You can see that in both instances it correctly identified the logged in user (sjobs), but only when run via sudo jamf -policy did it successfully run the subsequent commands as the logged in user.