3

How do you set a password to execute a command or script in Linux?

I need to avoid a script (in which user and password details are included) from being used/executed from unauthorized users. So is there any way to set password to execute a particular script.

Gilles 'SO- stop being evil'
  • 829,060
user42459
  • 321
  • I'm missing environmental information here. Would a script calling another script make it? Kinda Python compiled script for a bit of security by obscurity? – 41754 Jul 09 '13 at 07:13
  • 1
    @uprego - bad idea. Use sudo, obscurity != security! – slm Jul 09 '13 at 07:24
  • @slm - bad myth. Security by obscurity is a valid approach when being a trustable environment and or is just about preventing naïve users damage things. I said environmental information was missing. – 41754 Jul 09 '13 at 07:32
  • 5
    @uprego - not a myth at all. People can do what they want so long as they understand the tradeoffs. In this scenario there is a perfectly good choice already provided by most modern Linux installations, sudo. – slm Jul 09 '13 at 07:39

3 Answers3

5

Sudo might be the way to go.

Have your script owner and executable by a specific user and don't allow access from other users, 700 permissions for example.

Second, edit your sudoers file using visudo and add a line as the following:

%your_group ALL=path_to_script/script

All the users that are capable of running the script have to be added to your_group.

So, whoever is not part of your_group won't be able to run the script. The alternative can be for you to specific just the username.

username ALL=path_to_script/script
BitsOfNix
  • 5,117
1

You need to ensure that the password is only readable by authorized users. Don't store the password in the script, store it in a separate file that you read from the script. It's a lot easier to manage permissions this way. If you store credentials in the script, it's hard to be sure where they'll end up: they may be inadvertently copied around, they should be entered in version control, etc.

Separating the credentials from the script has a second and arguably more important benefit. It separates “permission to execute the script” from “permission to access the resource”, which is good, because you aren't really trying to prevent people from executing your script, you're trying to prevent people from accessing the resource. So set the permissions on the password file accordingly, and you'll be set.

The easy way to manage permissions is to create a group and put the users who are allowed to access the resource in that group. Let's call the group seniors, and say that users alice and bob are allowed to access the resource. Create a group called seniors (e.g. addgroup seniors), and add the users to the group (e.g. adduser alice seniors; adduser bob seniors). Make the password file owned by the group seniors and readable only by the group.

chgrp seniors password.txt
chmod u=rw,g=r,o= password.txt    # or chmod 640 password.txt for short

Maybe you want some users to be able to execute the script but not to have arbitrary access to the resource. You don't mention this in your question, but I'll explain how it can be done just in case.

Suppose that the users charlie and dominique must be able to execute that particular script, but not access the resource otherwise. Create a group called juniors and put these users into this group. (You don't actually need to create a group but it makes management easier.) Create a sudo rule that allows users in the group juniors to obtain the permissions of the group seniors, but only to execute one specific program — the script that reads the password file. Run visudo to add this line to the sudoers file:

%juniors ALL = (:seniors) /path/to/script ""

The juniors can execute the script by calling sudo -g seniors /path/to/script. The script will then run with the additional privileges conferred by the group seniors. Nonetheless the user who called sudo will not be able to access the password file (unless the script is buggy and can be tricked to leak it).

Note again that sudo is only useful if you need some people to be able to access the resource without knowing the password. It won't do anything for you if all you want is to restrict access to the password to certain users, and not allow anyone else to access the resource.

Gilles 'SO- stop being evil'
  • 829,060
0

Thanks to those that replied. The eventual answer I implemented is ... I found elsewhere on this site a routine for comparing passwords with /etc/shadow.

Because I am using a graphical interface I use zenity to prompt for a password. The person on the RPi does not know their password because of autologin Once a password is entered it is converted to a hash using the salt from the user account and the generated hash and original hash compared. If they are the same then the terminal program is run.

If the zenity cancelbutton is pressed or an incorrect password entered then nothing happens.

In order to run the script, which needs permissions to grep the /etc/shadow file I have an entry in /etc/sudoers.d/myfile = UserA ALL=(ALL) NOPASSWD: /opt/myFiles/startTerminal.sh

The script is:

    USERNAME=UserA
    PASSWD=$(zenity --forms --title=" " \
        --text="Enter Password" \
        --add-password="" )

    if [[ $? -eq 0 ]]; then
        export PASSWD
        ORIGPASS=`grep -w "$USERNAME" /etc/shadow | cut -d: -f2`
        export ALGO=`echo $ORIGPASS | cut -d'$' -f2`
        export SALT=`echo $ORIGPASS | cut -d'$' -f3`
        GENPASS=$(perl -le 'print crypt("$ENV{PASSWD}","\$$ENV{ALGO}\$$ENV{SALT}\$")')
        if [ "$GENPASS" == "$ORIGPASS" ]; then
            /usr/bin/lxterminal &
            exit 0
        fi
    fi
KennM
  • 1