Guake 3.8.5 does not execute commands provided by --execute-command=

[ghost]

Debian Sid
KDE Plasma Version : 5.24.3
KDE Framework: 5.90
QT Version: 5.15.2
Kernel : 5.16.0
Graphics X11

After upgrading to 3.8.5 my guake startup scripts do not execute properly anymore

Script:

#!/usr/bin/zsh
sleep 6
/usr/local/bin/guake --hide --rename-tab="Term1" &
sleep 1
/usr/local/bin/guake -n " " -r "Term2" &
sleep1
/usr/local/bin/guake -n " " -r "Term3" &
sleep 1
/usr/local/bin/guake -n " " -r "Term4" &
sleep 1
/usr/local/bin/guake -n " " -r "Term5" &
sleep 1
/usr/local/bin/guake -n " " -r "Htop&Logs" --execute-command="/usr/bin/sh /home/guest/scripts/tmux-log-diagnostic" &
sleep 1
/usr/local/bin/guake -n " " -r "enp3s0" -e /usr/bin/sh "/home/guest/scripts/tmux-network-diagnostic-enp3s0" &
sleep 1
/usr/local/bin/guake -n " " -r "enp4s0" -e /usr/bin/sh "/home/guest/scripts/tmux-network-diagnostic-enp4s0" &
sleep 1
/usr/local/bin/guake -n " " -r "plateau" -e "/usr/bin/sh /usr/bin/ssh [email protected]" &
sleep 1
/usr/local/bin/guake -n " " -r "OD"   -e "/usr/bin/ssh [email protected]" &
sleep 1
/usr/local/bin/guake -n " " -r "FS"     -e "/usr/bin/ssh [email protected]" &
sleep 1
/usr/local/bin/guake -n " " -r "orage" -e "/usr/bin/ssh [email protected]" &
sleep 1
/usr/local/bin/guake -n " " -r "doiz"  -e "/usr/bin/ssh [email protected]" &
sleep 1
/usr/local/bin/guake -n " " -r "irc"    -e "/usr/bin/irssi" &

After the script runs it normally would execute all of these commands no problem, after the update it wont work.

https://imgur.com/4B5H9xp

The tabs are not being renamed and my ssh, sh, and irssi sessions aren't opening, it just opens a tab in my home directory for each command in the script.

This is the error output i get when I run the command from a terminal (it gives me this output for each failed tab that opens):

Spawning new terminal at  
Traceback (most recent call last):
  File "/usr/local/bin/guake", line 10, in <module>
    sys.exit(exec_main())
  File "/usr/lib/python3/dist-packages/guake/main.py", line 633, in exec_main
    if not main():
  File "/usr/lib/python3/dist-packages/guake/main.py", line 552, in main
    remote_object.execute_command(options.command)
  File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 141, in __call__
    return self._connection.call_blocking(self._named_service,
  File "/usr/lib/python3/dist-packages/dbus/connection.py", line 652, in call_blocking
    reply_message = self.send_message_with_reply_and_block(
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownMethod: Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/dbus/service.py", line 662, in _message_cb
    (candidate_method, parent_method) = _method_lookup(self, method_name, interface_name)
  File "/usr/lib/python3/dist-packages/dbus/service.py", line 254, in _method_lookup
    raise UnknownMethodException('%s is not a valid method' % method_name)
dbus.exceptions.UnknownMethodException: org.freedesktop.DBus.Error.UnknownMethod: Unknown method: execute_command is not a valid method

[ivoshm]

Duplicate of #2042

[ghost]

Just so I'm clear on what the devs were putting down in #2042

After #2057 is reviewed the feature will be restored in a newer release?

[Davidy22]

Closing because duplicate, #2057 will reintroduce -e, but with different behavior. It will always create a new tab by default. I can technically force PRs through but this particular one I do want another maintainer's eyes on it to catch any way I may have accidentally reintroduced the vulnerability, although other maintainers check by fairly infrequently

[vasilakisfil]

@Davidy22 with always a new tab breaks a lot of my scripts. I used the dbus execute_command to run things from vim to guake, like compilation etc Why is it so problematic to allow it under an option, so the user completely takes responsibility ?

reintroducing it with always creating a new tab doesn't really solve much. It only solves the use case for startup scripts.

[Davidy22]

-e that doesn't force a new tab had a demonstrable security vulnerability where a malicious program can execute commands with root privileges if the guake session has elevated privileges. The behavior is changed to force new tab creation, because new tabs don't have elevated privileges, unless someone comes up with another preferable scheme for resolving the vulnerability.

[vasilakisfil]

is there a way to check whether the guake session actually has elevated privileges ? Or is this deadend, maybe I can come up with a PR, I desperately need this, it opens so many possibilities, it's all about automation and communication between different tools & Guake.

[Davidy22]

It's something of a nebulous problem since the term "elevated privileges" can include things that don't strictly include being sudo, there's a gradient of possible privilege levels that can still be undesirable to leak and some amount of them can be tied to arbitrary locally defined groups, also terminals can also just give people root privileges without even being logged in as root temporarily because most people have it set to remember that they entered a sudo password in the last 15 minutes. If you have a scheme implemented for definitively determining that the target terminal is unescalated then we can reintroduce the old behavior without reintroducing the vulnerability

[vasilakisfil]

@Davidy22 I was thinking that maybe we could include an Option that allows that in the Preferences, that also pinpoints on the security issues that such option has. Anyway, I ll find different ways to automate my flows, thanks for all the efforts in Guake, I have been using since 2010 and it has always been working great for me.

[Davidy22]

If the user is aware of the risk and has to manually opt into the old behavior through a warning then I guess it could be fine. I am a little not too thrilled about intentionally reintroducing a known security flaw that users can opt into, is there no other workable option available for your script? If it's something to do with multiple consecutive commands, perhaps some amount of ; may help, or you could create a new file and change the invocation to guake to run that separate script file that contains all the individual commands that you may have previously been trying to run in one terminal tab.

[fredmo]

I remark the execute command is not working if the settings shell is not on "user shell"

[fredmo]

And if I enable "run command as a login shell" , the --execute-command is not run.