4

I'm running a shell script using terminal from userA. In the middle of this shell script, I switch to userB user using su, but this asks me for the password of userB and I have to manually enter the password through terminal. I'm asking if there is a way so that I can enter the password automatically without having me to stay beside the machine to manually enter the password? As there is a loop in this script and I don't want to keep staying all the time looking at the terminal to enter the password of userB when it asks me. Or if there is a way I can put the password in my shellscript so that the terminal won't wait for me to manually enter it? Could anyone please advise how this could be done?

Improve this question
4
  • If you are familiar with ssh, you cas use ssh -i privkey userB@localhost where privkey is a password protected key. Else you can use sudo , which will ask you passwd less often.
    – Archemar
    Mar 15, 2015 at 9:28
  • 1
    @Archemar but there is no way I can put the password in my shellscript so that the terminal won't wait for me to manually enter it?
    – Tak
    Mar 15, 2015 at 10:17
  • use sudo option as The Sidhekin explain.
    – Archemar
    Mar 15, 2015 at 10:32
  • 2
    This looks like an instance of X-Y problem to me. I guess we all would be better off if you disclosed what you are trying to achieve by that script and relevant parts of its code, so that we can judge better which approach you should take.
    – Palec
    Mar 15, 2015 at 15:48

3 Answers 3

Reset to default
6

sudo also allows NOPASSWD on specific entries in the /etc/sudoers configuration, if you can get to that. Like:

userA ALL = (userB) NOPASSWD: ALL

This will give userA full access to userB without password. Should probably only be used if userA can be trusted to lock his screen whenever leaving it …

Alternatively, you can give userA access to only certain scripts. For instance:

userA ALL = (userB) NOPASSWD: /home/userB/scripts-for-userA/

This lets userA run any command in the directory /home/userB/scripts-for-userA/ as userB. It's still only as secure as those commands are, though.

Improve this answer
1
  • 1
    NOPASSWD: option can be skip, in which case userA's password will be asked once, and from time to time.
    – Archemar
    Mar 15, 2015 at 10:06
3

sudo will cache the password. But you rely need to ask if you are doing this right. Would it be better to change the permissions, so that you and userB have access to the same files?

Improve this answer
1
  • Thanks for your answer. Actually I can't change the permissions, I need to run su through the shell script. I think even sudo will ask me for the password because I will switch between the two users many times.
    – Tak
    Mar 15, 2015 at 9:41
1

You could move the stuff that's supposed to happen as UserB into a separate script that's suid to UserB. This will avoid the need to open up su to userB from userA if you don't want that blanket privilege.

Improve this answer
5
  • anytime you are thinking about making a suid script read super's man page. so much less work, so much more secure.
    – hildred
    Mar 15, 2015 at 21:10
  • @hildred mind adding a link to the man page, somewhere online? "man super" is not exactly something that gets useful search results
    – atk
    Mar 15, 2015 at 21:37
  • manpages.debian.org/cgi-bin/…
    – hildred
    Mar 15, 2015 at 21:59
  • @hildred thanks! I read much of the man page, and it seems like super is to replace suid root, but I don't see options for suid nonroot, which appears to be what the OP was looking for. Am I just overlooking something?
    – atk
    Mar 15, 2015 at 22:04
  • yes, and you can even have per user super tab files under individual user control. They are introduced as the second section. For entries in the main super.tab, group 5 options cover setting uid and such.
    – hildred
    Mar 15, 2015 at 22:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.