Sensible way to manage sudo commands from script?

[desmes]

Hey guys!

I have a script: ~/.local/bin/did-keyboard to manage the loading of xkeysnail with my specific configurations. I normally run it as did-xkeysnail --load, and it asks me for my sudo password since I have multiple sudo commands in there: sudo kill ..., sudo nohup xkeysnail... (since xkeysnail must be run as root).

The thing is that, for example, I want to bind some of these commands to keys (e.g. using XFCE keyboard binding program), so I want them to not ask for passwords. Also, from what I've seen, in some cases, during the invocation of some of these scripts (in a CLI) that contain sudo commands, I am not able to input my password.

What would be a sensible way of doing this? I've added this line to /etc/sudoers:

%wheel ALL=(ALL) NOPASSWD: /home/me/.local/bin/did-keyboard

But it obviously doesn't work since I don't even call the script with sudo, the sudo commands are inside of it. Should I just add all the commands inside the script to there? E.g.:

%wheel ALL=(ALL) NOPASSWD: /usr/bin/xkeysnail, /usr/bin/kill, /usr/bin/nohup

But this may be a bit overkill for what I want to do. What do you guys think?

Thanks in advance!

 

[DeletedAccount]

Sorry for the late reply! It seems to me that you don't want to use "sudo." A much simpler way to stop using it would be to run "sudo -s" in root. Then try running the keyboard-binded scripts.

 

[desmes]

Sorry for the late reply! It seems to me that you don't want to use "sudo." A much simpler way to stop using it would be to run "sudo -s" in root. Then try running the keyboard-binded scripts.

Thanks for the reply!
I'm sorry but I think I don't understand what you mean. Where do I have to run "sudo -s"? In my script? In the keybinding line of the XFCE keybinding program? And also, running "sudo -s" still asks for my password.

 

[DeletedAccount]

Thanks for the reply!
I'm sorry but I think I don't understand what you mean. Where do I have to run "sudo -s"? In my script? In the keybinding line of the XFCE keybinding program? And also, running "sudo -s" still asks for my password.

Oh, I meant in the terminal. It will give you root privileges in the terminal. After running the command and entering your password, you will no longer need to type out "sudo" or provide a password for administrator commands for what I believe to be the rest of the session. You could probably create a script that runs "sudo -s) at terminal startup.

Also, if what you were doing in your original post (which you thought was overkill) works, you should definitely try that.

%wheel ALL=(ALL) NOPASSWD: /usr/bin/xkeysnail, /usr/bin/kill, /usr/bin/nohup

 

[desmes]

I understand now, thanks a lot for the tip! I guess it's somehow tricky what I want to do

 

[Crippled]

The 21st century way.

 

[desmes]

The 21st century way.

Anti-CLI? How would you do something like this with a GUI?

 

[Tolkem]

What would be a sensible way of doing this?

Maybe, you could increase the sudo password timeout? If I understand correctly, you'd like to avoid typing your sudo passwd time and again, right? Well, this is certainly a way to achieve that.

sudo nano /etc/sudoers #I use nano but you may use vi as well

Locate this line

Defaults        env_reset

and edit it so it looks like this

Defaults        env_reset, timestamp_timeout=NN

Where NN is your new timeout value in minutes. i.e. 30. Save the file and that's it. Now, you won't have to type in your passwd for as long as the timeout you've set.

 

[Tolkem]

The 21st century way.

I like GUIs too, specially the terminal as I have it always open and do lots of stuff with it, yes, I can do some of that stuff with a GUI too, but then the CLI approach is way faster. Being "anti-cli" in Linux kind of defeats the purpose of using Linux in the first place, as it provides methods and tools to do things a GUI can't. You can do most of what you can in a GUI within the CLI, but the opposite isn't true. Don't fear the CLI! Embrace its power and beauty!

 

[Tolkem]

I state facts and not delousional falsehoods. There is nothing specail about the terminal. The Command Line Interface is ancient. The G.U.I. was created to make computing intuetive which makes computers easier to use and for the user to operate the computer faster. How is the command line faster when it takes so much time searching the Internet for the command due to the command line being counter intuitive as it's not just English, is bastardize abbreviation of English, and Gibberish?

1. Once you know the commands you need to use, you don't need to search the internet.
2. The terminal is a GUI too, to use the CLI, so if you use that GUI to use the CLI, it is faster than waiting for a bloated GUI to start, then click here, click there, and so on to accomplish a simple task.
Like I said, I like GUIs too and use a lot of them, but I too think the CLI/Terminal(a GUI) is faster and much more powerful too.

 

[Tolkem]

Delusional.

LoL If you're not able to manage how to use a terminal, that doesn't mean most people can't be. In fact, you'd be surprised at how many want to learn how to use a terminal and issue commands the proper way, so they can use their time more efficiently, so instead of wasting it in typing "delusional" in a Linux forum, they actually learn how to do stuff in the CLI(terminal)GUI LoL

 

[dos2unix]

Delusional.

There are a lot of things you can do from the command line, you can't do in the GUI.
Also if you ever go into professional enterprise Linux server administration, (say
in a data center) these servers won't have Xwindows installed on them.
So you have no choice but to learn CLI.

 

[f33dm3bits]

Delusional.

Microsoft even created Powershell because they realized the power of a good commandline for a sysadmin. Microsoft also recently created a package manager, winget. The commandline allows you to automate system tasks yourself, which can’t be done in a graphical interface. As already mentioned managing remote systems without GUI in datacenters but even with a difference between desktop and server systems, the commandline is even very useful on desktop systems for power users.

Everything in Gnu/Linux is a file, meaning anything you can do in the GUI you can get done in the commandline and more. Lastly there is logic to how the commandline interface works, if you can’t figure out and understand that logic you are ging to have a hard time in any IT job because all IT jobs require you to understand logic.

 

[KGIII]

Right now, I'm building a browser from source. Yup... Good thing I know how to use the terminal.

The ignorant decry those things they can't understand.

 

[KGIII]

Thread cleaned. User warned.

I expect this to be the end of the matter. Thanks.

 

[wizardfromoz]

Not quite (but nice work) it ain't over until the fat lady sings and I am the fat lady

I am going to move this Thread to Command Line , where scripting inquiries are best handled.

There, @desmes you may meet a nice fellow named Jas @JasKinasis who is one of our scripting gurus (as well as other talents) and he may have some valuable input for you.

@desmes don't be daunted with the disturbance above - we have 42,467 Members at time of writing, that is like a moderate sized city and there are bound to be a few disputes. David @KGIII and I are pretty moderate Moderators, but we can be the police if we need to be, in order to safeguard our "citizens" and maintain the integrity of this site

So hang on to your hats and Wizard will take us on a magic carpet ride to Command Line. Fasten your seatbelts and no smoking.

Chris Turner
wizardfromoz

 

[f33dm3bits]

@desmes You could try to if either setuid or capabilities work for you, don't know if the latter is available under any distribution. If you try setuid then try it first by setting setuid on your main script: ~/.local/bin/did-keyboard

 

[wizardfromoz]

Just one small error in that first article to note - at one point, it mentions

setgit

That should be

setgid

... like the other references, likely a typo

Cheers

Wiz

 

[desmes]

@wizardfromoz Thanks for the work! I really didn't understand what that guy was on about jajajaj

@f33dm3bits Thanks for the information and the resources. But I don't think I fully understand how the `setuid` approach may work for my situation.

I've added the `setuid` bit to the script. Then I've made `root` the owner of it (that's what I should do, right? It's the whole point of the `setuid` bit If I understand correctly). But now I can't execute the script, since I'm not the owner of the file. Therefore, I've changed the group owner to my group. This is how it looks now:

-rwsr-xr-x 1 root didac 25 31. Mär 09:17 /tmp/test-script.sh

I can now execute the script (without using sudo), but it seems like the lines inside of it are still not run with root privileges, since there's a single line: sudo echo test, and it still prompts me for my password.
What am I missing? Thanks again

 

[f33dm3bits]

I did some testing and figured out the problem, it seems setuid and setguid only work with executable binaries not with shell scripts, which I knew but forgot about that little detail.

My test script.

#!/bin/bash

ME="$(sudo whoami)"
echo "$ME"

ls -l testme.sh
-rwxr-xr-x 1 tux tux 44 Mar 31 09:40 testme.sh

So knowing that setuid and setguid only work for binaries I think your only option is to configure those specific commands to be allowed to run with sudo without asking for a password since looking at the results from my test below that seems to work.

I have sudo configured like this for my user.
(ALL) NOPASSWD: /usr/bin/whoami

When I run it now it gets executed as root without asking for a password.

bash -x testme.sh
++ sudo whoami
+ ME=root
+ echo root
root