How to password-protect a script on Linux?
Clash Royale CLAN TAG#URR8PPP
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
add a comment |
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
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. Usesudo
, 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
add a comment |
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
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
shell-script permissions security access-control authorization
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. Usesudo
, 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
add a comment |
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. Usesudo
, 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
add a comment |
3 Answers
3
active
oldest
votes
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
3
You typically shouldn't edit your/etc/sudoers
file directly, use the toolvisudo
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 usevisudo
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
add a comment |
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.
add a comment |
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
add a comment |
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
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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
3
You typically shouldn't edit your/etc/sudoers
file directly, use the toolvisudo
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 usevisudo
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
add a comment |
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
3
You typically shouldn't edit your/etc/sudoers
file directly, use the toolvisudo
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 usevisudo
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
add a comment |
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
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
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 toolvisudo
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 usevisudo
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
add a comment |
3
You typically shouldn't edit your/etc/sudoers
file directly, use the toolvisudo
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 usevisudo
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
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered Jul 10 '13 at 1:26
Gilles
528k12810581583
528k12810581583
add a comment |
add a comment |
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
add a comment |
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
add a comment |
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
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
answered Dec 19 '18 at 14:16
KennM
11
11
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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