How to password-protect a script on Linux?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












2














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.










share|improve this question























  • 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?
    – uprego
    Jul 9 '13 at 7:13






  • 1




    @uprego - bad idea. Use sudo, obscurity != security!
    – slm
    Jul 9 '13 at 7: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.
    – uprego
    Jul 9 '13 at 7: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 9 '13 at 7:39















2














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.










share|improve this question























  • 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?
    – uprego
    Jul 9 '13 at 7:13






  • 1




    @uprego - bad idea. Use sudo, obscurity != security!
    – slm
    Jul 9 '13 at 7: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.
    – uprego
    Jul 9 '13 at 7: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 9 '13 at 7:39













2












2








2


1





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.










share|improve this question















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.







shell-script permissions security access-control authorization






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jul 9 '13 at 20:04









Gilles

528k12810581583




528k12810581583










asked Jul 9 '13 at 7:10









user42459

111114




111114











  • 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?
    – uprego
    Jul 9 '13 at 7:13






  • 1




    @uprego - bad idea. Use sudo, obscurity != security!
    – slm
    Jul 9 '13 at 7: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.
    – uprego
    Jul 9 '13 at 7: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 9 '13 at 7:39
















  • 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?
    – uprego
    Jul 9 '13 at 7:13






  • 1




    @uprego - bad idea. Use sudo, obscurity != security!
    – slm
    Jul 9 '13 at 7: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.
    – uprego
    Jul 9 '13 at 7: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 9 '13 at 7:39















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?
– uprego
Jul 9 '13 at 7:13




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?
– uprego
Jul 9 '13 at 7:13




1




1




@uprego - bad idea. Use sudo, obscurity != security!
– slm
Jul 9 '13 at 7:24





@uprego - bad idea. Use sudo, obscurity != security!
– slm
Jul 9 '13 at 7: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.
– uprego
Jul 9 '13 at 7:32





@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.
– uprego
Jul 9 '13 at 7:32





5




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 9 '13 at 7:39




@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 9 '13 at 7:39










3 Answers
3






active

oldest

votes


















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





share|improve this answer


















  • 3




    You typically shouldn't edit your /etc/sudoers file directly, use the tool visudo to do edits.
    – slm
    Jul 9 '13 at 7:22











  • updated the answer with the tools for editing. thanks @slm
    – BitsOfNix
    Jul 9 '13 at 7:42










  • You should only use visudo to edit /etc/sudoers. sudoedit won't check the file's syntax.
    – user26112
    Jul 9 '13 at 11:27











  • guess I got lucky with sudoedit without breaking it, updated answer. thanks
    – BitsOfNix
    Jul 9 '13 at 11:35










  • The question as asked doesn't call for or benefit from sudo: to keep credentials away from certain users, all it takes is to not give them read permission on the file that contains the credentials.
    – Gilles
    Jul 10 '13 at 1:27



















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.






share|improve this answer




























    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("$ENVPASSWD","$$ENVALGO$$ENVSALT$")')
    if [ "$GENPASS" == "$ORIGPASS" ]; then
    /usr/bin/lxterminal &
    exit 0
    fi
    fi





    share|improve this answer




















      Your Answer








      StackExchange.ready(function()
      var channelOptions =
      tags: "".split(" "),
      id: "106"
      ;
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function()
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled)
      StackExchange.using("snippets", function()
      createEditor();
      );

      else
      createEditor();

      );

      function createEditor()
      StackExchange.prepareEditor(
      heartbeatType: 'answer',
      autoActivateHeartbeat: false,
      convertImagesToLinks: false,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: null,
      bindNavPrevention: true,
      postfix: "",
      imageUploader:
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      ,
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      );



      );













      draft saved

      draft discarded


















      StackExchange.ready(
      function ()
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f82293%2fhow-to-password-protect-a-script-on-linux%23new-answer', 'question_page');

      );

      Post as a guest















      Required, but never shown

























      3 Answers
      3






      active

      oldest

      votes








      3 Answers
      3






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      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





      share|improve this answer


















      • 3




        You typically shouldn't edit your /etc/sudoers file directly, use the tool visudo to do edits.
        – slm
        Jul 9 '13 at 7:22











      • updated the answer with the tools for editing. thanks @slm
        – BitsOfNix
        Jul 9 '13 at 7:42










      • You should only use visudo to edit /etc/sudoers. sudoedit won't check the file's syntax.
        – user26112
        Jul 9 '13 at 11:27











      • guess I got lucky with sudoedit without breaking it, updated answer. thanks
        – BitsOfNix
        Jul 9 '13 at 11:35










      • The question as asked doesn't call for or benefit from sudo: to keep credentials away from certain users, all it takes is to not give them read permission on the file that contains the credentials.
        – Gilles
        Jul 10 '13 at 1:27
















      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





      share|improve this answer


















      • 3




        You typically shouldn't edit your /etc/sudoers file directly, use the tool visudo to do edits.
        – slm
        Jul 9 '13 at 7:22











      • updated the answer with the tools for editing. thanks @slm
        – BitsOfNix
        Jul 9 '13 at 7:42










      • You should only use visudo to edit /etc/sudoers. sudoedit won't check the file's syntax.
        – user26112
        Jul 9 '13 at 11:27











      • guess I got lucky with sudoedit without breaking it, updated answer. thanks
        – BitsOfNix
        Jul 9 '13 at 11:35










      • The question as asked doesn't call for or benefit from sudo: to keep credentials away from certain users, all it takes is to not give them read permission on the file that contains the credentials.
        – Gilles
        Jul 10 '13 at 1:27














      5












      5








      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





      share|improve this answer














      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






      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Jul 9 '13 at 11:34

























      answered Jul 9 '13 at 7:18









      BitsOfNix

      4,11321632




      4,11321632







      • 3




        You typically shouldn't edit your /etc/sudoers file directly, use the tool visudo to do edits.
        – slm
        Jul 9 '13 at 7:22











      • updated the answer with the tools for editing. thanks @slm
        – BitsOfNix
        Jul 9 '13 at 7:42










      • You should only use visudo to edit /etc/sudoers. sudoedit won't check the file's syntax.
        – user26112
        Jul 9 '13 at 11:27











      • guess I got lucky with sudoedit without breaking it, updated answer. thanks
        – BitsOfNix
        Jul 9 '13 at 11:35










      • The question as asked doesn't call for or benefit from sudo: to keep credentials away from certain users, all it takes is to not give them read permission on the file that contains the credentials.
        – Gilles
        Jul 10 '13 at 1:27













      • 3




        You typically shouldn't edit your /etc/sudoers file directly, use the tool visudo to do edits.
        – slm
        Jul 9 '13 at 7:22











      • updated the answer with the tools for editing. thanks @slm
        – BitsOfNix
        Jul 9 '13 at 7:42










      • You should only use visudo to edit /etc/sudoers. sudoedit won't check the file's syntax.
        – user26112
        Jul 9 '13 at 11:27











      • guess I got lucky with sudoedit without breaking it, updated answer. thanks
        – BitsOfNix
        Jul 9 '13 at 11:35










      • The question as asked doesn't call for or benefit from sudo: to keep credentials away from certain users, all it takes is to not give them read permission on the file that contains the credentials.
        – Gilles
        Jul 10 '13 at 1:27








      3




      3




      You typically shouldn't edit your /etc/sudoers file directly, use the tool visudo to do edits.
      – slm
      Jul 9 '13 at 7:22





      You typically shouldn't edit your /etc/sudoers file directly, use the tool visudo to do edits.
      – slm
      Jul 9 '13 at 7:22













      updated the answer with the tools for editing. thanks @slm
      – BitsOfNix
      Jul 9 '13 at 7:42




      updated the answer with the tools for editing. thanks @slm
      – BitsOfNix
      Jul 9 '13 at 7:42












      You should only use visudo to edit /etc/sudoers. sudoedit won't check the file's syntax.
      – user26112
      Jul 9 '13 at 11:27





      You should only use visudo to edit /etc/sudoers. sudoedit won't check the file's syntax.
      – user26112
      Jul 9 '13 at 11:27













      guess I got lucky with sudoedit without breaking it, updated answer. thanks
      – BitsOfNix
      Jul 9 '13 at 11:35




      guess I got lucky with sudoedit without breaking it, updated answer. thanks
      – BitsOfNix
      Jul 9 '13 at 11:35












      The question as asked doesn't call for or benefit from sudo: to keep credentials away from certain users, all it takes is to not give them read permission on the file that contains the credentials.
      – Gilles
      Jul 10 '13 at 1:27





      The question as asked doesn't call for or benefit from sudo: to keep credentials away from certain users, all it takes is to not give them read permission on the file that contains the credentials.
      – Gilles
      Jul 10 '13 at 1:27














      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.






      share|improve this answer

























        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.






        share|improve this answer























          1












          1








          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.






          share|improve this answer












          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.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Jul 10 '13 at 1:26









          Gilles

          528k12810581583




          528k12810581583





















              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("$ENVPASSWD","$$ENVALGO$$ENVSALT$")')
              if [ "$GENPASS" == "$ORIGPASS" ]; then
              /usr/bin/lxterminal &
              exit 0
              fi
              fi





              share|improve this answer

























                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("$ENVPASSWD","$$ENVALGO$$ENVSALT$")')
                if [ "$GENPASS" == "$ORIGPASS" ]; then
                /usr/bin/lxterminal &
                exit 0
                fi
                fi





                share|improve this answer























                  0












                  0








                  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("$ENVPASSWD","$$ENVALGO$$ENVSALT$")')
                  if [ "$GENPASS" == "$ORIGPASS" ]; then
                  /usr/bin/lxterminal &
                  exit 0
                  fi
                  fi





                  share|improve this answer












                  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("$ENVPASSWD","$$ENVALGO$$ENVSALT$")')
                  if [ "$GENPASS" == "$ORIGPASS" ]; then
                  /usr/bin/lxterminal &
                  exit 0
                  fi
                  fi






                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Dec 19 '18 at 14:16









                  KennM

                  11




                  11



























                      draft saved

                      draft discarded
















































                      Thanks for contributing an answer to Unix & Linux Stack Exchange!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid


                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.

                      To learn more, see our tips on writing great answers.





                      Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


                      Please pay close attention to the following guidance:


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid


                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.

                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function ()
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f82293%2fhow-to-password-protect-a-script-on-linux%23new-answer', 'question_page');

                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown






                      Popular posts from this blog

                      How to check contact read email or not when send email to Individual?

                      Bahrain

                      Postfix configuration issue with fips on centos 7; mailgun relay