7

I'm writing a shell script where most commands don't require root privileges. The script should be ran by the administrator. But I would like to be able to "su" to a normal user account for the parts of the scripts that don't require root privileges. This would minimize the number of operations done with root privileges and would improve security.

Is there a linux command to do that?

I know it is possible to su to any user account but I don't want to rely on the hypothesis that a particular username exists on the machine.

I thought of creating a temporary account for the time of the script and delete it at the end of the script. But if I don't set a password on this account, wouldn't an attacker be able to use it during the short lifetime of the account? I can't set the user shell to /sbin/nologin because apparently this prevents executing commands in a shell script "suing" to the account.

Thanks for your help.

John Smith Optional
  • 472
  • 2
  • 9
  • 18
  • 1
    Why not just have your admin run the script from their normal, unprivileged user account, and sudo as needed ? – Sirex May 14 '13 at 22:58
  • 3
    `But if I don't set a password on this account` - Don't set an empty password. Set a Disabled password. Store a `*` in the password field for the account you create. You can use the account, but you cannot authenticate to it using password authentication. All your services accounts are already doing this. See your `/etc/shadow`. – Zoredache May 14 '13 at 23:01
  • Thanks for the tip. Can it be done directly with the useradd command? – John Smith Optional May 15 '13 at 10:10
  • Can you show us the command which creates temp user? – Čamo Jan 27 '21 at 10:58

6 Answers6

13

I would personally invert your strategy and run the script as a non-privileged user, with sudo used to run the commands requiring root privileges. Is there any specific reason you need to run the script as root?

To answer your question however, you can use the -c flag to run a specific command as a user:

su someuser -c "touch /tmp/file"

Reference: http://linux.die.net/man/1/su

Craig Watson
  • 9,370
  • 3
  • 30
  • 46
  • 3
    This is the Right Way. – Michael Hampton May 15 '13 at 05:05
  • 1
    Thanks, I think I'm going to do that but that means I'll have to take care of a sudoers file on every machine and make sure they are synchronized. I guess you're right, though. This is the best way. – John Smith Optional May 15 '13 at 10:08
  • Just because something is the best way does not mean it answers the question or applies in all cases. For example, I am writing a script to check that the root user's password is not an old company default. Unfortunately su doesn't require a password when root runs it, so I need to de-escalate privileges so that I can re-escalate privileges but can't be sure any given account exists because this has to all happen at deployment time via kickstart. I'd rather not create a user I will only ever need once to do this. – James Shewey Jun 09 '16 at 15:59
  • you not doing that the best way, or the easy way – Sum1sAdmin Jan 18 '19 at 13:38
  • 1
    ... and if the user does not have a shell assinged to its account (as is the case of www-data on debian servers)... you can specify which shell to use with: `su www-data -s /bin/sh -c "touch /tmp/file"` – dasj19 Jul 26 '19 at 18:31
2

I don't want to rely on the hypothesis that a particular username exists on the machine.

There are advantages being the superuser... :-)

scriptuser_created=no
scriptuser=myuser
if ! id "$scriptuser" &>/dev/null
  adduser --system "$scriptuser"
  scriptuser_created=yes
fi
sudo -u "$scriptuser" command1
sudo -u "$scriptuser" command2
sudo -u "$scriptuser" command3
if [ yes = "$scriptuser_created" ]; then
  userdel "$scriptuser"
fi
Hauke Laging
  • 5,157
  • 2
  • 23
  • 40
0

The traditional solution to a problem like this is for a permanent user account to exist with precisely the access levels and permissions required by the program in question. Network services (like apache) often run as their own user, with privileges distinct from those of a normal interactive user and significantly less than root.

If root is running the script in the first place, they won't need to provide a password to su to another user, even if that user has a password.

Sparr
  • 770
  • 1
  • 5
  • 14
  • Thanks for your reply. I edited my message while you were replying. I added the requirement that I don't want to rely on the existence of a particular username on the machine. I'd like to be able to distribute the script without worrying about what other user accounts exist on the computer and how they are set up. – John Smith Optional May 14 '13 at 22:25
0

Su stands for substitute user. You can use su to change to another user. So if you are superuser and want to run something as another user just su username and run the command.

tim
  • 1
0
#! /bin/bash
#  (GPL3+) Alberto Salvia Novella (es20490446e)


execute () {
    function="${1}"
    command="${2}"
    error=$(eval "${command}" 2>&1 >"/dev/null")

    if [ ${?} -ne 0 ]; then
        echo "${function}: $error"
        exit 1
    fi
}


executeAsNonAdmin () {
    function="${1}"
    command="${2}"

    eval setPasswordAsker="SUDO_ASKPASS=/usr/libexec/openssh/ssh-askpass"
    run="runuser ${SUDO_USER} --session-command=\"${setPasswordAsker}\" --command=\"${command}\""
    execute "${function}" "${run}"
}


executeAsNonAdmin "" "${@}"
-1

Insert this at the beginning of your shell script.

# please run as foo user
if [[ $EUID -ne 1234 ]]; then
        echo "This script must be run as foo"
        exit 1
fi

You can set the shell to nologin.

Add sudo privileges for user foo to do the remaining root-required operations only via carefully crafted sudoer configuration.

dmourati
  • 24,720
  • 2
  • 40
  • 69
  • I'm unsure if this answers the original question - it wasn't asking if the script could detect if it was running as the correct user, but the script should be run as root and drop to a non-privileged user where appropriate. – Craig Watson May 14 '13 at 22:37