Grant non-admin sudo privilege, but with `~` being his own home~ I have heard it to be adviced that, with the general idea of least privilege, Unix-like users should create another account without sudo privilege, in addition to the built-in account with sudo privilege. 
In Mac, this translates to be: one should create a staff account for daily use, in addition to the admin account that comes with the computer, being reserved only when necessary.

For concreteness, say bruce is a staff, which I use daily, and batman is an admin, which I use only when necessary. 
But how can I, while logging in batman, perform sudo tasks, on behalf of bruce, that is to say with bruce's own ~ and $(whoami) just as if I were logging in as bruce with privilege? 

To illustrate this, define /User/bruce/test.sh:

#!/usr/bin/env bash

whoami
cd ~ &amp;&amp; pwd
ls ~/Library/Preferences/Preferences/


(Yes, I have done chmod 744 test.sh) I chose the last line for artificial illustration purpose that, normally it seems, ~/Library/Preferences/Preferences/ is not accessible to a staff (i.e., a non-admin).

What I intend to receive, is bruce, /Users/bruce, and successful ls output. 



The first attemp is that, indeed, if I open bruce's terminal, but login the bash of batman (in order to get sudo privilege), and run

sudo /Users/bruce/test.sh


I get root, /Users/batman, and successful ls output of ~/Library/Preferences/Preferences/, showing that the home is batman's; this is no wonder. 

Or, a possible duplicate (a) asserts that sudo -i -u bruce enables me to execute commands as bruce. 
But no! If I (as above) open bruce's terminal, login the bash of batman, and run

sudo -i -u bruce /Users/bruce/test.sh


I get bruce, /Users/bruce, and ls: : Permission denied.

Yet another possible duplicate (b) states that sudo -H -u bruce uses bruce's home. 
Well, again when I open bruce's terminal, login the bash of batman, and run 

sudo -H -u bruce bash /Users/bruce/test.sh


I too get bruce, /Users/bruce, and ls: : Permission denied.



The reader might think my request is unreasonable; but I just want to know whether it is possible to temporarily grant sudo privilege to a staff -- which may be convenient at times. 
For example, if this can be done, when I am doing some short script I need no longer avoid $(whoami) or ~, making it more flexible. 
Or, when I run a short script what site I googled suggests, nor do I have to replace $(whoami) by bruce and/or ~ by /Users/bruce. 

The last time, as far as I recall, I was irritated by the restriction of privilege, is probably when I ran a layperson-made script I googled, in order to install a LaTeX font. 

However, at present I can recollect one instance only. 
That is, after I, while logging in batman, brew-ed something using homebrew (for it requires sudo privilege), and logout-ed back as bruce and brew-ed something other. 
Homebrew complained a large number of incorrect permissions of certain folders under /usr/local, and urged me to run sudo chown -R $(whoami) blablabla. 
It seemed to me that brew had set certain permission to batman's own, and it drove me crazy to fix them one by one. 

What do you do to get around the moment, for example, that brew requires sudo, while using a staff account? 
Or, after all, is the practice that daily-used account should contain least privilege, simply unrealistic?
There is a flaw in bruce's home folder probably: the permissions of ~/Library/Preferences/Preferences are wrong. Therefore the script doesn't work as expected.

Check the following output in my environment executing the script logged in as admin. I slightly modified the script and replaced ls ~/Library/Preferences/Preferences by ls -la ~/Library/Preferences | grep "loginwindow"

/Users/bruce/bin/sh/test-env.sh
batman
/Users/batman
-rw-------    1 batman  staff     192 27 Nov 13:42 com.apple.loginwindow.plist
-rw-------    1 batman  staff     198 24 Okt 21:43 loginwindow.plist

sudo /Users/bruce/bin/sh/test-env.sh
root
/Users/batman
-rw-------    1 batman  staff     192 27 Nov 13:42 com.apple.loginwindow.plist
-rw-------    1 batman  staff     198 24 Okt 21:43 loginwindow.plist

sudo -i -u bruce /Users/bruce/bin/sh/test-env.sh
bruce
/Users/bruce
-rw-------    1 bruce  staff      95 27 Nov 13:40 com.apple.loginwindow.plist
-rw-------    1 bruce  staff     198 27 Nov 13:36 loginwindow.plist

sudo su bruce
/Users/bruce/bin/sh/test-env.sh
bruce
/Users/bruce
-rw-------    1 bruce  staff      95 27 Nov 13:40 com.apple.loginwindow.plist
-rw-------    1 bruce  staff     198 27 Nov 13:36 loginwindow.plist
$USERNAME = root #check this by entering `env` in the shell additionally

sudo su -l bruce
/Users/bruce/bin/sh/test-env.sh
bruce
/Users/bruce
-rw-------    1 bruce  staff      95 27 Nov 13:40 com.apple.loginwindow.plist
-rw-------    1 bruce  staff     198 27 Nov 13:36 loginwindow.plist
$USERNAME = &lt;empty&gt;




Also: there is a major misunderstanding how sudo/su really works. Your admin batman never runs a command "on behalf" of another user. If you enter "sudo some_command" or "sudo -i -u user some_command" it's always the super user's elevated position (and the privilege of an admin to run sudo as determined by the sudoers file and "make himself super user" temporarily) which "executes the command successfully on behalf of another user".

If you have to execute commands with escalated privileges on a daily base with your non-admin user, add him to the sudoers file and add a restricted number of commands only.

Example (control Apache web server):

bruce ALL=(ALL) /usr/sbin/apachectl


or without the requirement to enter a password after executing sudo apachectl as bruce:

bruce ALL=(ALL) NOPASSWD: /usr/sbin/apachectl


Or modify the scripts appropriately to stay within bruce's realm.

That said the advice/practice that "the daily user shouldn't be a sudoer" is still valid.



Homebrew is a different beast: it's designed to be installed by one user only - an admin user. Most apps/executables provided by the homebrew environment can be launched by a standard user after modifying the user's $PATH though or using the full path.

Several how-tos exist how to set up homebrew as a multi-user environment (e.g. My Homebrew Multi User Setup). I don't know if this still applies to newer OS X systems/brew versions.