Run linux program as another user

How can I run as another user?

This is the bash code that should be runned. So first it substitutes the user to openproject and than runs all the code:

su openproject -c "bash -l" cd ~/openproject git checkout Gemfile.lock git pull bundle install RAILS_ENV="production" bundle exec rake db:migrate RAILS_ENV="production" bundle exec rake db:seed RAILS_ENV="production" bundle exec rake assets:precompile 

su - openproject -c "cd ~openproject/openproject" su - openproject -c "git checkout stable" su - openproject -c "git checkout Gemfile.lock" su - openproject -c "git pull" su - openproject -c "bundle install" su - openproject -c "RAILS_ENV="production" bundle exec rake db:migrate" su - openproject -c "RAILS_ENV="production" bundle exec rake db:seed" su - openproject -c "RAILS_ENV="production" bundle exec rake assets:precompile" 

but this does not run properly and at every steps asks for password. How can the translated script be improved so it works? UPDATE 1: After receiving sugestions about this I am the point where the code has been modified into:

cd ~openproject/openproject sudo -u openproject git checkout stable sudo -u openproject git checkout Gemfile.lock sudo -u openproject git pull # the output is good thill here sudo -u openproject bundle install sudo -u openproject RAILS_ENV="production" bundle exec rake db:migrate sudo -u openproject RAILS_ENV="production" bundle exec rake db:seed sudo -u openproject RAILS_ENV="production" bundle exec rake assets:precompile 

UPDATE 2: After trying the suggestion from Dmitry Vasilyanov I found that if i insert the -i it will simulate as user login. However this is not the final way to do it. If I run echo $PATH after logging in as openproject the ouput is /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/home/openproject/.rvm/bin If I run echo $PATH after su openproject -c «bash -l» the output is /home/openproject/.rvm/gems/ruby-2.1.0/bin:/home/openproject/.rvm/gems/ruby-2.1.0@global/bin:/home/openproject/.rvm/rubies/ruby-2.1.0/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/home/openproject/.rvm/bin

Источник

Background

I’m trying to restart some programs ( mail-notification and stalonetray ) regularly, as they appear to die frequently. I want to set restart them whenever NetworkManager reconnects. Hence, I have them triggered by a script in /etc/NetworkManager/dispatcher.d/ .

Scripting

#!/bin/bash sudo -u foo_user pkill mail-notificati -x sudo -u foo_user DISPLAY=:0 mail-notification & 

This works fine if I run it directly as a user. However, if I call it from root’s script, it fails. I am prompted to enter the passwords for mail-notification ; it cannot read Gnome Keyring. How can I run this program as foo_user in every way?

What does «in every way» mean? Every program that a user runs can have different environment, so saying that (for example) DISPLAY should be set for it to be «in every way» doesn’t make much sense. You’d need to define this question more for it to make sense.

@ChrisDown I mean I want it to work when running the script as root as it does when running the script as foo_user . I appreciate that DISPLAY isn’t necessarily relevant here, but included it as an example of what I was doing.

That still doesn’t clarify, because «doing the same thing when run as root as when run as a user» doesn’t make sense — an environment is per-process, not per-user.

@ChrisDown Sorry, I’m afraid I don’t understand the distinction in this case. Here, I’m asking to run the mail-notification process as in foo_user ‘s environment.

How do you know foo_user is logged in, and on which display? On a single-user system it’s perhaps reasonable to assume that it’s always :0.0 but it is not reasonable to assume that the user is logged in at all times. Anyway, this makes more sense to run within the X session script of foo_user , which will remove both your original problem and the complications it caused you to want to try to solve.

4 Answers 4

In 2021

In short:

To run a command as another user you can use this commands:

runuser -u user — command
can be used only by root to run commands as another user.
do not require authentication.
do not create log messages.
has permission limitations and issues.

su — user -c command
can be used by any user.
require authentication as target user.
create message in /var/log/auth.log or /var/log/secure .

sudo -u user command
can be used by the user with root privileges or the user from the sudoers file.
require authentication as current user (you).
create message in /var/log/auth.log or /var/log/secure .

pkexec —user user command
can be used by any user.
require authentication as target user.
create message in /var/log/auth.log or /var/log/secure .
replacement for GUI tools such as gksu or gksudo .

More info:

Run a GUI application as another user:

If you want to run a GUI application as another user, you need first allow to the target user connecting to your display:
xhost +si:localuser:user
then use runuser / su / sudo / pkexec to run the application,
and then use xhost to prevent the subsequent connections:
xhost -si:localuser:user

Excellent answer! I tried to use this to run spotify as a non-privileged system user. Your answers, especially for running a GUI app, worked for me. However, I did neet to pass in my DISPLAY var through sudo using the -E flag. Also, I was ignorant and didn’t realize localuser is that literal string. Finally, a gui app may fail to various other issues with expecting a normal user’s profile. HTH

Regarding GUI: Is this safe though? Can user send arbitrary input after having been given access to the display?

You can always use good old su :

This command opens a sub-shell as the user you want to impersonate. As root you can use it without being prompted for a password.

su foo_user -c whatevercommandyouwant

I’m not sure what -x is (I get su: invalid option — ‘x’ ), but after removing that, it still fails as per the question.

Hi, sorry for the confusion, but my aim is not to provide a one shot solution but to tell you how the command su works. If you did a direct cut and paste you may have got an error. But, that’s exactly why I added a link to the su man page as the first thing. Please cut and paste this into the shell and see what it says 😉

Sorry, I still don’t understand. Are you suggesting that su will provide a different env to sudo that should fix my problem? If so, then that doesn’t seem to be the case.

Yes. Again: man7.org/linux/man-pages/man1/su.1.html » su allows to run commands with a substitute user and group ID. When called without arguments, su defaults to running an interactive shell as root. For backward compatibility, su defaults to not change the current directory and to only set the environment variables HOME and SHELL (plus USER and LOGNAME if the target user is not root). » anyway sudo has nothing to do with that, sudo su does. sudo grants permissions to run commands that require specific privileges to your user.

If you want to interact with a GUI from a process that isn’t started from that GUI, you need to set a few environment variables: at least DISPLAY , possibly also XAUTHORITY if it isn’t in the default location, and for many modern programs you need to set DBUS_SESSION_BUS_ADDRESS .

But a more reliable approach for your problem would be to not restart those programs from NetworkManager. In addition to the difficulty of successfully launching them, you also need to worry about whether you’re logged in at all, and if there might be other users and other displays to consider, and so on. Instead, kill those programs, but don’t restart them. In your normal session, instead of starting them directly, start them from a supervisor that restarts them if they die. I think systemd includes this functionality (but I don’t know how to use it); or you can use dedicated supervisor programs such as monit, supervise, …

Read, copy and install run-as , a Bash and a Python script which wrap up usage of machinectl , xhost and of managing running dbus and setting variables to run a graphical application for you:

To run a graphical application do

References

You must log in to answer this question.

Linked

Related

Hot Network Questions

Subscribe to RSS

To subscribe to this RSS feed, copy and paste this URL into your RSS reader.

Site design / logo © 2023 Stack Exchange Inc; user contributions licensed under CC BY-SA . rev 2023.7.14.43533

Linux is a registered trademark of Linus Torvalds. UNIX is a registered trademark of The Open Group.
This site is not affiliated with Linus Torvalds or The Open Group in any way.

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.

Источник

Run script as another user on Linux

One difference between your examplar question and your question is that the other question uses user1 ALL=(user2) NOPASSWD: /home/user2/bin/test.sh but you omit the = in your version. That might be all that’s wrong; it might be innocent. It’s worth checking.

I made sure it had the equals and still got the same results. The output is owned by wayne so I know its running correct script.

3 Answers 3

The answer is change from su to sudo.

su is primarily for switching users, while sudo is for executing commands as other users. The -u flag lets you specify which user to execute the command as:

sudo -u wayne '/home/wayne/script2.sh' 

gives Sorry user is not allowed to execute

Solution: In order to run commands/scripts as another user on linux/unix you need sudo permission and run the following formula:

For example:

sudo -H -u wayne bash -c 'echo "user:$USER|home:$HOME|action:run_script"; ./home/wayne/script.sh' 

from Documentation:

 sudo allows a permitted user to execute a command as the superuser or another user, as specified by the security policy. -H The -H (HOME) option requests that the security policy set the HOME environment variable to the home directory of the target user (root by default) as specified by the password database. Depending on the policy, this may be the default behavior. -u user The -u (user) option causes sudo to run the specified command as a user other than root. To specify a uid instead of a user name, use #uid. When running commands as a uid, many shells require that the '#' be escaped with a backslash ('\'). Security policies may restrict uids to those listed in the password database. The sudoers policy allows uids that are not in the password database as long as the targetpw option is not set. Other security policies may not support this. 

Источник

Run a shell script as another user that has no password

I would like to run a script from the main ubuntu shell as a different user that has no password. I have full sudo privileges, so I tried this:

sudo su -c "Your command right here" -s /bin/sh otheruser 

Then I have to enter my password, but I am not sure if that script is now really running under that user. How can I confirm that the script is really running under that user now?

10 Answers 10

You can do that with su or sudo , no need for both.

sudo -H -u otheruser bash -c 'echo "I am $USER, with uid $UID"' 

The relevant parts of man sudo :

-H The -H (HOME) option requests that the security policy set the HOME environment variable to the home directory of the target user (root by default) as specified by the password database. Depending on the policy, this may be the default behavior. 

(Starting from Ubuntu 19.10, -H is no longer needed as this is now the default behaviour. See: How does sudo handle $HOME differently since 19.10?)

-u user The -u (user) option causes sudo to run the specified command as a user other than root. To specify a uid instead of a user name, use #uid. When running commands as a uid, many shells require that the '#' be escaped with a backslash ('\'). Security policies may restrict uids to those listed in the password database. The sudoers policy allows uids that are not in the password database as long as the targetpw option is not set. Other security policies may not support this. 

su can only switch user without providing a password if you are root. See Caleb’s answer

You can modify the /etc/pam.d/su file to allow su without password. See this answer.

If you modified your auth file to the following, any user that was part of group somegroup could su to otheruser without a password.

auth sufficient pam_rootok.so auth [success=ignore default=1] pam_succeed_if.so user = otheruser auth sufficient pam_succeed_if.so use_uid user ingroup somegroup 

rubo77@local$ su otheruser -c 'echo "hello from $USER"' hello from otheruser 

Источник