[SOLVED] Openbox rc.xml and custom scripts

HisDudeness · 2017-09-09 14:29:06

I have a standalone openbox environment, and one thing I can't seem to get to work (even if it did on my previous computer) is running my custom scripts with keyboard shortcuts. I'm sure I'm missing something stupid but I can't figure out what, can you help me find it?

What I'm doing is adding a keyboard shortcut like this:

    <keybind key="S-Print">
      <action name="Execute">
        <startupnotify>
          <enabled>true</enabled>
          <name>Screenshot</name>
        </startupnotify>
        <command>maimsave</command>
      </action>
    </keybind>

which is supposed to start, upon pressing shift+print, the following script, which simply uses maim to save the current screen to a file with a name I decided:

#!/bin/bash

IFS=$'\n'

maim -- $(date +%Y.%m.%d\ %H:%M:%S).png

The folder in which the script is has already been added to the path, both in .bashrc and in .zshrc (I use zsh). In fact, running the script from my terminal emulator works like a charm, while pressing shift+print gives the following error message:

Failed to execute child process "maimsave" (no such file or directory)

What am I missing here?

Last edited by HisDudeness (2017-10-09 14:43:53)

ayekat · 2017-09-09 15:56:55

HisDudeness wrote:

The folder in which the script is has already been added to the path,

How do you add it to the path? Does it work if you specify the full path to the script?
Also, how do you start openbox?

HisDudeness · 2017-09-09 16:00:45

Thanks for your reply.

I added it to the path by adding this lines in .(z/ba)shrc

PATH=$PATH:/home/dude/Scripts
export PATH

I start openbox with lightdm, which calls openbox-session and not openbox. In fact, all instructions in autostart do work.
Copying the script to /usr/bin works. That makes me think something is wrong in the way I added my folder to the path, or that openbox needs another way for that.

Slithery · 2017-09-09 16:06:14

HisDudeness wrote:

The folder in which the script is has already been added to the path, both in .bashrc and in .zshrc (I use zsh). In fact, running the script from my terminal emulator works like a charm, while pressing shift+print gives the following error message:
Failed to execute child process "maimsave" (no such file or directory)

Your shell rc files are only sourced by interactive shells, so Openbox can't find the binary in your path. Either move the binary to /usr/local/bin (or somewher else in the system PATH) or just use its path in your keybind.

I just use the path method in my herbstluftwm config...

...
hc keybind $Mod-x spawn ~/bin/dmenu2-power-menu
...

In your case you'd just change the <command></command> field to include the path.

Last edited by Slithery (2017-09-09 16:16:39)

HisDudeness · 2017-10-09 10:54:15

Sorry for disappearing for a month, work drives me crazy.

Indeed it seems I have no alternative to specifying full path. No problem at all, as it doesn't change.

I've got another problem though. My laptop's brightness keys do not work on their own, so I made a custom script which accepts some option to alter my screen's light's intensity. It is pretty rudimental, I know (I suck at programming) but it works. When executed with the terminal. Applied to rc.xml, it doesn't. Here's the script:

#!/bin/bash

max=`more /sys/class/backlight/intel_backlight/max_brightness`

#right now it is set according to Cleo's max brightness: 416. steps of 83 so that it goes to 1 min (416-1=415 is 5*83). It should be nice to have a config script which, depending on max brightness, finds a divisor of max-1 which gives an acceptable number of steps and sets it as the variation
#echo $(( $(more /sys/class/backlight/intel_backlight/max_brightness)*$1/100 )) > /sys/class/backlight/intel_backlight/brightness

current=`more /sys/class/backlight/intel_backlight/brightness`

re='^[0-9]+$' #regular expression to check if it's a number

if [ -z "$1" ]; then

     echo -e "Usage: bright [ARGUMENT]\n\nARGUMENT:\n\nmax or min\tSet brightness to the maximum or minimum\n\n+ or -\t\tIncrease or decrease brightness\n\nFrom 1 to $max\tSet brightness manually to the desired value"

elif [ $1 = "+" ]; then
    
    sudo tee /sys/class/backlight/intel_backlight/brightness <<< $((current + 83))

elif [ $1 = "-" ]; then
    
    sudo tee /sys/class/backlight/intel_backlight/brightness <<< $((current - 83))

elif [ $1 = "max" ]; then
    
    sudo tee /sys/class/backlight/intel_backlight/brightness <<< $max

elif [ $1 = "min" ]; then
    
    sudo tee /sys/class/backlight/intel_backlight/brightness <<< 1
    
elif [[ $1 =~ $re && $1 > 0 && $1 < 417 ]]; then

    sudo tee /sys/class/backlight/intel_backlight/brightness <<< $1

else
    
    echo "Error: invalid argument. Input a number between 0 and $max"

fi

Essentially, the script ("bright") is based on my laptop's (Cleo) max brightness being 416. Options are +, -, max, min and any number between 1 and 416. + and - increase and decrease brightness by 83, which is one fifth of the brightness range. I've set my rc.xml so that pressing Fn+F8/9 (the keys which have the brightness down/up function) invoke bright - and bright +

    <keybind key="XF86MonBrightnessUp">
      <action name="Execute">
        <startupnotify>
          <enabled>true</enabled>
          <name>Brightness Up</name>
        </startupnotify>
        <command>/home/dude/Scripts/bright +</command>
      </action>
    </keybind>
    <keybind key="XF86MonBrightnessDown">
      <action name="Execute">
        <startupnotify>
          <enabled>true</enabled>
          <name>Brightness Down</name>
        </startupnotify>
        <command>/home/dude/Scripts/bright -</command>
      </action>
    </keybind>

Unfortunately, when I press the keys, nothing happens. Brightness isn't altered and no error message is displayed. The only thing that comes to my mind is that tee outputs to stdout as well, and launching it without a terminal doesn't allow it to output the new brightness' value. I don't know if that prevents it from writing the value to /sys/class/backlight/intel_backlight/brightness as well, or I'm just saying blasphemy. Anyone can help me on that?

Trilby · 2017-10-09 11:28:41

How does it "work" when run from a terminal? Do you need to enter your password (or have recently entered a sudo command)?

I certainly hope you didn't add "tee" to a nopasswd entry in your sudoers file as that would allow any user to do absolutely anything without a password.

HisDudeness · 2017-10-09 11:45:26

My user is in the wheel group, which is allowed to use sudo without entering any password. Is that bad for security?

I would certainly prefer a way to alter brightness without entering sudo, but I couldn't find any other way than writing to that file. Should I alter its permissions instead?

Last edited by HisDudeness (2017-10-09 11:45:49)

Trilby · 2017-10-09 11:54:15

HisDudeness wrote:

My user is in the wheel group, which is allowed to use sudo without entering any password. Is that bad for security?

So any command can be run at any time as root without a password? Yes, that is very bad. That is virtually equivalent to running everything as root all the time. You do need the magic "sudo" word in a command to do any real damage, so perhaps you prevent yourself from accidentally typing the wrong command, but any attacker or malicious script (even scripts in webpages) could quite readily destroy or take over your entire system. "Readily" here means they wouldn't even need to try, ridiculous script-kiddy attacks that most of us would just laugh off as silly as they'd never actually work would quite easily cripple or destroy your system.

You can enter the script itself in sudoers as not requiring a password, then run the script with sudo (from your key binding). That way no password is needed, but the only thing an attacker or malicious script could do without your password is change your screen brightness (they could be annoying, but not dangerous).

On the script itself, you may want to consider a case rather than many ifs:

#!/bin/bash

backlight=/sys/class/backlight/intel_backlight/
val=$(< $backlight/brightness)
max=$(< $backlight/max_brightness)
min=1
step=83

case $1 in
	+) val=$((val + step)) ;;
	-) val=$((val - step)) ;;
	max) val=$max ;;
	min) val=$min ;;
	[0-9]*) val=$1 ;;
	*) echo -e "Usage: bright [ARGUMENT]\n\n"
		"ARGUMENT:\n\n"
		"max or min\tSet brightness to the maximum or minimum\n\n"
		"+ or -\t\tIncrease or decrease brightness\n\n"
		"From 1 to $max\tSet brightness manually to the desired value" ;;
esac

[[ val -lt $min ]] && val=$min
[[ val -gt $max ]] && val=$max

tee $backlight/brightness << $val

Last edited by Trilby (2017-10-09 11:55:45)

HisDudeness · 2017-10-09 12:06:24

Thank you, I've never thought about that... I'll change my ways right now. Should I also prevent sudo from executing without prompting for password if I entered it little time ago? Or is that no threat to security?

I don't remember which problem I ran into when trying to use case, but that script you made in a few minutes is so much better. I guess the difference shows. I'd like to really build up my scripting and programming abilities up but I've got so little free time... dammit.

Thanks for the heads up, for the better script and the solution... I'll try that right now.

Trilby · 2017-10-09 12:20:29

HisDudeness wrote:

Thank you, I've never thought about that... I'll change my ways right now. Should I also prevent sudo from executing without prompting for password if I entered it little time ago? Or is that no threat to security?

Allowing repeated sudo commands without a password during that timeout period is generally considered safe (I have this enabled, as do I suspect most archers). The key difference is that this timeout policy only applies within a session/process: for example, if you do a `sudo pacman -Syu` and enter your password, then a minute later in that same shell you enter `sudo pacman -S <some-package>` you would not need to re-enter your password - this doesn't pose any real danger*. If you open two terminal windows, and enter the -Syu in one of them and enter your password, then a moment later try the -S command in the other, it will still ask for your password (as the timeout period only applies within the single shell session).

Contrast this to having any command being able to be run as root with no password. Now it's not just your active shell session, but *any* process can run root commands. Depending on the securty of your web browser, even some javascript embedded in a webpage could get root access to your system (most modern browsers do have some form of sandboxing and would hinder such activity, but relying solely on the browser here may not be wise). Any PKGBUILD you ran makepkg on could do anything it wanted and essentially circumvent any and all checks that makepkg does for proper behavior. Any program you run could spawn background processes that could just wipe your harddrive, or open remote sockets, or anything else they wanted, simply by forking a shell and passing a command with the word "sudo" in front of it.

---

*note: one exception is if you work with your computer in a busy area and you are prone to stepping away - at which point someone could sneak in and type a command in your shell session. But this is such a contrived example that it isn't particularly relevant. More importanrly "physical access is root access": if a malicious agent can sit at your keyboard without your supervision, there are bigger things to worry about. But if find your self in such a situation, if you enter your password for a sudo command and need to step away, simply close that terminal/shell before you leave and any risk from the sudo timeout is mitigated. (Better yet use a screen lock). But in any case, for the average joe, security risks don't come from someone targetting us in a cafe and trying to get into our computer, but rather the risks to average users come from broadcast attacks on websites, in emails, etc.

Last edited by Trilby (2017-10-09 12:25:40)

HisDudeness · 2017-10-09 12:29:14

Thank you very much for your helpfulness and patience. Don't want to go off-topic here or abuse any of the two, warn me if I'm doing something wrong, but I've got a couple of problems with your script:

/home/dude/Scripts/bright: line 23: warning: here-document at line 23 delimited by end-of-file (wanted `$val')
tee: /sys/class/backlight/intel_backlight/brightness: Permission denied

The second thing is due to the fact that the last line is issued even if the script is launched as non-root just to get help. But the first I can't get a grasp on, as everything I've found searching around in the internet involves scripts in which an EOF is manually specified.

Trilby · 2017-10-09 12:42:49

Ah, yes - sorry about that. There's also another error from a typo in the two conditionals just before that. I just quickly knocked out the script as an example of using a case statement and some other simplifications - I don't use it so I hadn't tested it. Here are some fixes:

#!/bin/bash

backlight=/sys/class/backlight/intel_backlight/
old=$(< $backlight/brightness)
new=$old
max=$(< $backlight/max_brightness)
min=1
step=83

case $1 in
	+) new=$((new + step)) ;;
	-) new=$((new - step)) ;;
	max) new=$max ;;
	min) new=$min ;;
	[0-9]*) new=$1 ;;
	*) echo -e "Usage: bright [ARGUMENT]\n\n"
		"ARGUMENT:\n\n"
		"max or min\tSet brightness to the maximum or minimum\n\n"
		"+ or -\t\tIncrease or decrease brightness\n\n"
		"From 1 to $max\tSet brightness manually to the desired newue" ;;
esac

[[ $new -lt $min ]] && new=$min
[[ $new -gt $max ]] && new=$max

[[ $new -ne $old ]] && tee $backlight/brightness << $new

This way the tee will only be attempted if an actual change was requested. It will still give a permission denied error if a change is requested and the script wasn't run as root/sudo. If you want to have a more elegant error message for that case, you could use the following for the last lines instead:

[[ $new -eq $old ]] && exit
if [[ $(uid -u) -eq 0 ]]; then
   tee $backlight/brightness <<<$new
else
   echo "You must be root or use sudo..."
fi

This exits the script if no change has been requested and only continues if a change has been requested. Then it checks whether the effective user id is 0 (root) and runs tee if it is, otherwise echos a message.

HisDudeness · 2017-10-09 13:10:43

Thanks! I had solved the second problem by defining a "change" variable defaulted to 1, which I set to 0 in the default case (if no change is made). Then, I had indeed set tee to run only if $EUID is zero, and a message to be shown elif the change variable remained 1. I always am contorted, this is the first thing I have to correct in my scripting. Your way works much better.

I don't know why, but I always had to put the echo in just one line, otherwise if would take further lines as commands. In definitive, this script works like a charm, with keybindings too:

#!/bin/bash

backlight=/sys/class/backlight/intel_backlight/
old=$(< $backlight/brightness)
new=$old
max=$(< $backlight/max_brightness)
min=1
step=83

case $1 in
	+) new=$((new + step)) ;;
	-) new=$((new - step)) ;;
	max) new=$max ;;
	min) new=$min ;;
	[0-9]*) new=$1 ;;
	*) echo -e "Usage: bright [ARGUMENT]\n\nARGUMENT:\n\nmax or min\tSet brightness to the maximum or minimum\n\n+ or -\t\tIncrease or decrease brightness\n\nFrom 1 to $max\tSet brightness manually to the desired newue" ;;
esac

[[ $new -lt $min ]] && new=$min
[[ $new -gt $max ]] && new=$max

[[ $new -eq $old ]] && exit
if [[ $EUID -eq 0 ]]; then
   tee $backlight/brightness <<<$new
else
   echo "The command must be run as root"
fi

Just one last question: I've read putting sudos inside scripts is horrible practice. But, if I have to run the whole script with sudo, each command in it gets run as root. I've also read some commands (such as make or makepkg) are to be absolutely not run as root. Are the great majority of commands indifferent to being run as regular user or administrator? How do I know if in my script I have to run as root I have not put a command which has to be run as regular user? If I have one, should I "sudo -u regularuser" it?

Trilby · 2017-10-09 14:05:19

HisDudeness wrote:

I always had to put the echo in just one line, otherwise if would take further lines as commands

Oops, yes, another silly mistake on my part. Evidence that knowing in principle how to write scripts doesn't make one except from careless errors. I intended to put a line contination "\" at the end of each on of those lines in the echo command (except for the last). Having it all on one line is perfectly good - just stylistically it's often a good idea to avoid excessively long lines of code and break them with continuation lines for better readability. But that is a purely stylistic choice.

HisDudeness wrote:

I've read putting sudos inside scripts is horrible practice. But, if I have to run the whole script with sudo, each command in it gets run as root.

I certainly don't think putting sudo in a script is a horrible practice. The principle of least privilege would lead one to only put sudo inside the script on the specific commands that absolutely require it. However, this principle is at odds with the password requirements: in a script that will only be run at the command line, having sudo inside the script specifically where it is needed may be best - the user will be prompted for the password only when required.

There is also a practice of putting "sudo -v" at the start of any such script, then "sudo" before just the commands that require root access. This kind of gets the best of both worlds. The initial "sudo -v" ensures that the user running is a valid sudo user (they are prompted for the password right at the start). From them on further sudo commands may not need a password if the timeout hasn't expired - but only those commands that have sudo infront of them are actually ran as root.

But either of these approaches are at odds with having your script be bound to a key in your window manager: you can't enter a password. So you will need to put *something* in your sudoers file as not requiring a password. Using your script's name and running that script with sudo is the best option for this. Otherwise you would need to add "tee" to sudoers to run without a password - that'd be very bad (simplest case one could `sudo tee /etc/sudoers < my_new.sudoers` and completely replace your sudoers file with one that allows them to do anything).

HisDudeness wrote:

How do I know if in my script I have to run as root I have not put a command which has to be run as regular user? If I have one, should I "sudo -u regularuser" it?

I don't know of any single check or rule. The only command intended to run as your user that would fail as root are those that directly access files in your home directory (as root ~ or $HOME are expanded to /root, not /home/username). But there are many commands it would be unwise to run as root - particularly any gui process should be avoided. In the case of makepkg, it knows it should run as root, so it will just exit with an error if you attempt to run it as root. And it doesn't do so because it would *fail* to run as root, but because it's authors are cautious enough to know if it did run as root, a poorly written PKGBUILD could have catastrophic results. So it's more like a blender that will not turn on unless the lid-switch signals the presence of the lid: the blender could run just fine without a lid, but the engineers put in a safety check to prevent people from using it that way.

Referring back to the principle of least privilege, though, if in doubt, don't run anything as root. Anything that needs to be run as root will provide an error message (e.g., permission denied). Then you know you need to modify something.

HisDudeness · 2017-10-09 14:43:34

Thank you very much for everything, Trilby. Not only you have solved my initial problem (I couldn't run that script in rc.xml as it needed root password, and the solution was to put a specific rule in sudoers file) and you provided me a beautiful script to alter brightness, but you have also taught me a lot! I feel like I learned many fundamental things I missed.

And thanks to slithery too for solving my original problem, which had to do with running custom scripts in rc.xml in general, without them requiring root password.

This topic is solved, I'll proceed to edit the title.

Last edited by HisDudeness (2017-10-09 14:46:06)

Arch Linux

#1 2017-09-09 14:29:06

[SOLVED] Openbox rc.xml and custom scripts

#2 2017-09-09 15:56:55

Re: [SOLVED] Openbox rc.xml and custom scripts

#3 2017-09-09 16:00:45

Re: [SOLVED] Openbox rc.xml and custom scripts

#4 2017-09-09 16:06:14

Re: [SOLVED] Openbox rc.xml and custom scripts

#5 2017-10-09 10:54:15

Re: [SOLVED] Openbox rc.xml and custom scripts

#6 2017-10-09 11:28:41

Re: [SOLVED] Openbox rc.xml and custom scripts

#7 2017-10-09 11:45:26

Re: [SOLVED] Openbox rc.xml and custom scripts

#8 2017-10-09 11:54:15

Re: [SOLVED] Openbox rc.xml and custom scripts

#9 2017-10-09 12:06:24

Re: [SOLVED] Openbox rc.xml and custom scripts

#10 2017-10-09 12:20:29

Re: [SOLVED] Openbox rc.xml and custom scripts

#11 2017-10-09 12:29:14

Re: [SOLVED] Openbox rc.xml and custom scripts

#12 2017-10-09 12:42:49

Re: [SOLVED] Openbox rc.xml and custom scripts

#13 2017-10-09 13:10:43

Re: [SOLVED] Openbox rc.xml and custom scripts

#14 2017-10-09 14:05:19

Re: [SOLVED] Openbox rc.xml and custom scripts

#15 2017-10-09 14:43:34

Re: [SOLVED] Openbox rc.xml and custom scripts

Board footer