I often need to run at jobs as a different user. I've always done something like
$ echo "$PWD/batchToRun -parameters" | sudo su - otheruser -c "at now"
batchToRun is also scheduled to run via otheruser's crontab. This works out well until batchToRun starts depending on subtle side-effects of settings of environmental variables -- like LANG (sort anyone?) -- that are passed in from the environment of the user running sudo.
I typically don't want to log in as otheruser; it's a semi-privileged account and I would like a "paper trail" of its associated activity so that I can go back and see exactly what was done, by whom, when, etc.
Besides the obvious rewriting batchToRun to be independent of such settings, what's a good way to ensure that the sudoer's environment doesn't contaminate the target environment?
Note: this is on FC7 (sudo version 1.6.8p12) and other old distros, so any shiny new features of sudo/su/at (notably, the ability to pass an argument with -i to sudo) are outside my grasp.
Update: it turns out that the su - otheruser is actually a sufficient firewall between the users and that my contamination is coming from something in the interactive startup sequence. I still like the env edit capability, though.
You could strip the environment before you run at:
echo "command ..." | env - PATH="$PATH" sudo su - otheruser -c "at now"
You can also arrange for sudo to do this for you by setting the env_reset option. For example, you could give your user access to run the at command as otheruser directly (rather than sudo to root and then to the other user) and then set env_reset with a Defaults command for that user or that command (see the sudoers man page).
But the above is probably the easiest solution without changing how you're generally doing things today.
Any "contamination" of otheruser's environment should be limited to the at command's environment. When it actually comes time to run batchToRun, it will be run by otheruser using its typical default environment. That is, only at now is run in the shell spawned by the su sudo command.
Related
I need to run a command as a different user in the %post section of an RPM.
At the moment I am using a bit of a hack via python but it can't be the best way (it does feel a little dirty) ...
%post -p /usr/bin/python
import os, pwd, subprocess
os.setuid(pwd.getpwnam('apache')[2])
subprocess.call(['/usr/bin/something', 'an arg'])
Is there a proper way to do this?
If /usr/bin/something is something you are installing as part of the package, install it with something like
attr(4755, apache, apache) /usr/bin/something
When installed like this, /usr/bin/something will always run as user apache, regardless of what user actually runs it.
The accepted answer here is wrong IMO. It is not often at all you want to set attributes to allow anyone execute something as the owner.
If you want to run something as a specific user, and that user doesn't have a shell set, you can use su -s to set the shell to use.
For example: su -s /bin/bash apache -c "/usr/bin/something an arg"
There are two ways this script can be run: When the user opens the pkg file and goes through the normal GUI setup, or when an admin (or savvy user) runs sudo installer -pkg /path/to/Installer.pkg -target /. For the second one, I want to know when the script was run in this mode so I can make more admin-friendly decisions like not opening another GUI. How do I know when my pkg is installed via the command line?
I'm hoping for some environment variable or something similar.
Running the script via sudo will change the values of certain variables and add others in. Your script could check for the existence of those variables (or their values) to make a determination as to whether the installer was run via sudo.
Values that would get updated:
HOME
LOGNAME
MAIL
Values that would get set:
SUDO_COMMAND -- the command that was run via sudo
SUDO_GID -- the GID of the user that ran sudo
SUDO_UID -- the UID of the user that ran sudo
SUDO_USER -- the username of the user that ran sudo
My recommendation would be to check for the existence of the SUDO_COMMAND environment variable; it is unlikely to be set for a non-sudo installation, and would be set for a sudo-based installation.
Reference: sudo 1.8.20 manual - ENVIRONMENT section
Since this was being run by the installer command, the COMMAND_LINE_INSTALL environment variable is set to 1. When opening the pkg normally, this variable is not set at all.
So:
if [ $COMMAND_LINE_INSTALL ]; then
# Do stuff for CLI land
else
# Do stuff for GUI land
fi
I need to run a command as a different user in the %post section of an RPM.
At the moment I am using a bit of a hack via python but it can't be the best way (it does feel a little dirty) ...
%post -p /usr/bin/python
import os, pwd, subprocess
os.setuid(pwd.getpwnam('apache')[2])
subprocess.call(['/usr/bin/something', 'an arg'])
Is there a proper way to do this?
If /usr/bin/something is something you are installing as part of the package, install it with something like
attr(4755, apache, apache) /usr/bin/something
When installed like this, /usr/bin/something will always run as user apache, regardless of what user actually runs it.
The accepted answer here is wrong IMO. It is not often at all you want to set attributes to allow anyone execute something as the owner.
If you want to run something as a specific user, and that user doesn't have a shell set, you can use su -s to set the shell to use.
For example: su -s /bin/bash apache -c "/usr/bin/something an arg"
How to run some commands in my installations scripts of deb-package (preinst, postinst, prerm, postrm) not from root but from current user (user that invoked the installation)?
root is the current user. You should never expect that the installation of the package is performed by sudo
You can check the SUDO_USER environment variable for the user that may have invoked the script, if the installation was performed from the context of a simple sudo dpkg -i - sudo may not have been installed, so the installation may have been performed by su, which means that the environment variable will not be set.
If you want to invoke scripts as that user you just invert the sudo - viz:
sudo -u $SUDO_USER -c <command to invoke>
but you need to ensure that you properly know the user that invoked the script - i.e. SUDO_USER could be root!
Typically, though, because you can have an arbitrary number of users on a Linux system, you should not do something like this, as it will leave the system in a state where only one user can use the package. You should create state/configuration on first invocation as the ordinary user.
Finally, don't expect a GUI, don't expect a terminal on the installation if it's just being shipped as a dpkg.
You need to be root in order to install something. If you install per-user configurations, they should normally be installed for all users.
Having said that, look into real vs effective uid.
I need use execute a command inside of a script in a Run Script build phase in Xcode 4 using sudo. However, the compiler complains:
sudo: no tty present and no askpass program specified
Anyone have a clever solution for this problem?
One solution is to place the sudo password in an executable shell script like the following:
#!/bin/bash
echo thesudopassword
This shell script might be called password.sh
Then, setup the environment variable SUDO_ASKPASS=password.sh
Once this is setup, the -A option can be passed to sudo. This option uses the ASKPASS program to obtain the sudo password. The ASKPASS program need only write the password to stdout.
So, for example,
sudo -A ditto -V /tmp/testserver.dst /
This is obviously a rather insecure solution, but it does work.
Two ideas that haven't been suggested yet, both of which are probably better/safer than the currently accepted answer:
First option would be to put the part of the script that needs to be run as root in a script file (.sh or something), and then make it setuid as root: chmod go-w,+sx scriptfile, sudo chown root scriptfile. This means that script will automatically run as root, which avoids you needing to authenticate to run it (just to change it). As long as its operation isn't subject to user input, this should be quite safe. (Of course, if you make a script that takes an input argument and deletes it or runs it, or does most anything else with it, that would not be safe.)
Second option would be to use applescript (possibly via osascript). Applescript allows you to do shell script "sudo command goes here" with administrator privileges, which will pop up a graphical dialog asking for a password.
The first of these options would be good for an automated environment, though it might not deal well with (for example) being checked into an SCM, or being sent to another user. The second option would work better with that, but requires a password input every time, so doesn't work as well for an automated build script.
Another solution to this problem is to modify sudoers file and add your account to it and state that you should never be asked for the sudo password. To accomplish this is fairly straightforward:
run:
sudo visudo
In the User privilege specification section add a line that looks like
youraccountname ALL=(ALL) NOPASSWD: ALL
Of course, this can be a dangerous thing to do, so be careful. I would suggest reading the man page for sudoers and visudo before going this route.
After much searching I found the following solution.
https://forum.juce.com/t/build-script-for-automatically-moving-built-aus-into-components-folder-xcode/13112
Summary
Create a keychain and store your admin password in the keychain
Create a script which uses /usr/bin/security to access the password In your run script,
Set the ASK_PASS env variable and use the -A option with sudo
You can either run commands directly as a administrator with the following (changing echo YourCommandHere > /tmp/hello to your command):
osascript -e 'do shell script "sudo echo YourCommandHere > /tmp/hello " with administrator privileges'
Or run a script in your source directory using:
osascript -e 'do shell script "bash -x $SOURCE_ROOT/MyAdminScript.sh 1>/tmp/build-log 2>/tmp/build-log.err" with administrator privileges'
This runs the script and logs it output to /tmp/build-log and /tmp/build-log.err
For useful variables in the script see https://help.apple.com/xcode/mac/8.0/#/itcaec37c2a6
You can also execute XCode giving it the project as parameter from the Terminal using sudo like this:
sudo /Developer/Applications/Xcode.app/Contents/MacOS/Xcode /path/to/your/project.xcodeproj
This is the easiest solution I could think of, but there may be some drawbacks, since you would be executing XCode as root.
No need to write your sudo password anywhere. Just open a terminal window and type
$ sudo echo "hello"
Once you've typed your password, it will be good for a while - not sure how long - and the shell spawned by Xcode will inherit this permission.
If you get the "no tty present" message again later, just repeat the procedure