[SOLVED] Safer option than this rather dodgy sudo method?

loadlover · 2017-09-04 16:55:10

Hi all,

Let's say that I'm logged in as user bo, who is a member of the wheel group, and as such, has sudo privilege. And let's say that bo's password is "ohmigod".

I, bo, want to have a script run a command as a user other than me (let's say, as user ken), so in the script I have:

echo ohmigod | sudo -Su ken pacman -S git

I've heard this is really unsafe - one reason being that the password I've supplied to run sudo will be saved in .bash_history.

Could you advise of a better, safer way?

Thanks,

Loady

Last edited by loadlover (2017-09-05 20:19:23)

Alad · 2017-09-04 17:10:01

Just use sudoers and NOPASSWD for selected commands.

Trilby · 2017-09-04 17:31:34

This is far too artificial to recommend actual alternatives. I assume you're not actually trying to run pacman like that. What are you really trying to do?

seth · 2017-09-04 19:30:06

nb. that the problem is not the shell/readline history. That's easy to avoid.
On top of that, your particular example btw. also calls a $PATH relative binary (bad. attackable)

The major issue with the general approach is that you store a password plaintext.

adesh · 2017-09-04 20:22:31

Slightly better (but obviously still insecure) way to provide password can be to store the password in a file with 0400 perms in ~ and use in the script like:

< .mypass sudo -Su ken somecommand

loadlover · 2017-09-04 20:43:22

seth wrote:

On top of that, your particular example btw. also calls a $PATH relative binary (bad. attackable)

I'm curious. By "$PATH relative binary", do you mean that the path could be directed at something other than what's expected? Probably not.. I dunno.

Loady

@Trilby: No, I'm not trying to run pacman this way. It was just the first command that came to mind.

Last edited by loadlover (2017-09-04 20:44:18)

Trilby · 2017-09-04 20:45:34

So ... (again) what are you really trying to do?

eschwartz · 2017-09-05 01:09:20

loadlover wrote:

seth wrote:
On top of that, your particular example btw. also calls a $PATH relative binary (bad. attackable)
I'm curious. By "$PATH relative binary", do you mean that the path could be directed at something other than what's expected? Probably not.. I dunno.

How do you think the script figures out what to do with `pacman` anyway...

exporting a custom $PATH before running scripts is *the* classic way of changing their behavior in unpredictable ways.

Also you still haven't explained why you think you need to do this, which is a bad idea not because the contents of a script will be inserted inline into ~/.bash_history (it won't) but because as seth said you have a text file sitting in your home folder containing your login password, and on top of that anyone running htop (or any other utility that lets you view the process tree) can see the `echo ohmigod | sudu -Su ...` command as your script runs it, even if the file itself is restricted so no other logged-in users can trivially read it.

So essentially, "I've heard this is really unsafe" is entirely correct. The better, safer way is to stop thinking there is any better, safer way to skip checking for permissions before doing things.

What are you trying to do, why are you trying to do it, and why don't you want to just ask for a password interactively *as sudo was designed to do*???

Last edited by eschwartz (2017-09-05 01:11:16)

loadlover · 2017-09-05 20:15:14

loadlover wrote:

one reason being that the password I've supplied to run sudo will be saved in .bash_history.

I do apologizse for this;) In this regard, I was referring to entry of said command at the prompt rather than to its use within a script.

Anyway, thanks for your help. I continue to learn in my roundabout fashion:)

Last edited by loadlover (2017-09-05 20:17:59)

Trilby · 2017-09-05 21:13:15

Erm ... so this is solved? How?

https://wiki.archlinux.org/index.php/Co … way_street

loadlover · 2017-09-05 21:53:24

Trilby wrote:

Erm ... so this is solved? How?
https://wiki.archlinux.org/index.php/Co … way_street

Trilby, if you look above, I said that I was interested in why such a 'dodgy' command was considered risky. That was my question. That is the title of the thread.

A couple of people have weighed in, providing some reasons why, and suggesting better alternatives. I am grateful for all the hints I have been provided - they give me some direction for further learning.

A horribly meaningless phrase that's become popular with political spokespeople, but which seems strangely apposite: will "Asked and answered" do?

Loady

PS: And if you really must know, today I am wearing a thong.

Slithery · 2017-09-05 22:10:02

Your question was actually...

loadlover wrote:

Could you advise of a better, safer way?

There are several different methods of achieving what you want - sudoers and policykit to name just two.
The appropriate method depends on the outcome you wish to achieve, which is why you were being asked for more details.

Without knowing exactly what it is you are attemping we can't give the correct advice.

Trilby · 2017-09-05 23:14:40

loadlover wrote:

PS: And if you really must know, today I am wearing a thong.

WTF is that. So you want to get an attitude because I was expecting you to provide the information needed to address the question you asked?

Well now I know 3 things about you: you wear a thong, you're a dipship, and you're certainly not worth me wasting my time trying to help you on these forums again. Consider my attempt to help you suitably punished.

ewaller · 2017-09-06 01:46:14

loadlover, I think we are done here as this is marked solved. I am glad it is, but let me close with :

https://wiki.archlinux.org/index.php/Co … esponsible
https://wiki.archlinux.org/index.php/Co … ther_users
https://wiki.archlinux.org/index.php/Co … _the_staff (Including fellows)

Inquiries as to how something is resolved are well within our community's norms. Apparently it had not been clear; a state with which I would have agreed at the time of the post to which you responded.

Arch Linux

#1 2017-09-04 16:55:10

[SOLVED] Safer option than this rather dodgy sudo method?

#2 2017-09-04 17:10:01

Re: [SOLVED] Safer option than this rather dodgy sudo method?

#3 2017-09-04 17:31:34

Re: [SOLVED] Safer option than this rather dodgy sudo method?

#4 2017-09-04 19:30:06

Re: [SOLVED] Safer option than this rather dodgy sudo method?

#5 2017-09-04 20:22:31

Re: [SOLVED] Safer option than this rather dodgy sudo method?

#6 2017-09-04 20:43:22

Re: [SOLVED] Safer option than this rather dodgy sudo method?

#7 2017-09-04 20:45:34

Re: [SOLVED] Safer option than this rather dodgy sudo method?

#8 2017-09-05 01:09:20

Re: [SOLVED] Safer option than this rather dodgy sudo method?

#9 2017-09-05 20:15:14

Re: [SOLVED] Safer option than this rather dodgy sudo method?

#10 2017-09-05 21:13:15

Re: [SOLVED] Safer option than this rather dodgy sudo method?

#11 2017-09-05 21:53:24

Re: [SOLVED] Safer option than this rather dodgy sudo method?

#12 2017-09-05 22:10:02

Re: [SOLVED] Safer option than this rather dodgy sudo method?

#13 2017-09-05 23:14:40

Re: [SOLVED] Safer option than this rather dodgy sudo method?

#14 2017-09-06 01:46:14

Re: [SOLVED] Safer option than this rather dodgy sudo method?

Board footer