Page MenuHomePhabricator

e's new sudo password pops up when it should not.
Closed, InvalidPublic


I have a script I run daily for years now to turn off my laptop display and activate external. I have an icon on my desktop I click on to call that script. Under E 22 with the new sudo password dialog. The new sudo password dialog coming up when it should not.


$ cat scripts/


if [[ -n "$(xrandr | grep ${HDMI}\ connected)" ]] &&
[[ -n "$(xrandr | grep ${LDSP}\ connected | grep 1920)" ]]; then
        xrandr  --output "${HDMI}" --auto --output "${LDSP}" --off
        sudo /etc/X11/xinit/99-synergyc
        xrandr  --output "${LDSP}" --auto --output "${HDMI}" --off
        sudo killall -9 synergyc

exit 0


# cat /etc/sudoers.d/wlt
wlt     ALL = NOPASSWD: /bin/echo mem > /sys/power/state
wlt     ALL = NOPASSWD: /etc/X11/xinit/99-synergyc
wlt     ALL = NOPASSWD: /etc/init.d/bluetooth
wlt     ALL = NOPASSWD: /etc/init.d/cupsd
wlt     ALL = NOPASSWD: /home/wlt/scripts/
wlt     ALL = NOPASSWD: /home/wlt/scripts/
wlt     ALL = NOPASSWD: /usr/bin/cpupower
wlt     ALL = NOPASSWD: /usr/bin/emerge
wlt     ALL = NOPASSWD: /usr/bin/killall

I have them set to nopasswd. Its worked fine for years.

FYI it does not come up when using it directly, sudo emerge ... , sudo /etc/init.d/cupsd start, etc. Only seems to come up with that script for some reason.

zmike reassigned this task from zmike to raster.Sep 19 2017, 8:33 AM
raster closed this task as Invalid.Sep 19 2017, 4:15 PM

E doesn't start the sudo password dialog. sudo does. All we do is:

export SUDO_ASKPASS=/usr/local/bin/enlightenment_askpass

Or effectively that in code. Nothing else. It is sudo itself that chooses to run the askpass binary if it wants a password. It is just told via environment variable what that binary is if it wants password. There is zero possible way for E to know what the sudo config is to specify password or not for sudo. It's also not E's task to know the intricacies of sudo's config and internals. E just runs a command you gave it (fork + exec) like the script. It doesn't know what happens inside that.

You may want to file a bug with sudo or the package maintainers of your distro if they patched it causing this issue.

O Arch LinuX I have set my user to NOPASSWD: for a long time ... and no password pops up (never has unless I disabled that NOPASSWD:). It still does not, and Arch has a general policy of not patching or messing with upstream code, thus why I suggest it might be patches your distro has applied.

That would not make sense, as if it was ask pass then it would fail when I close the dialog. It is not needed. This stuff has been in place for years. Nothing was updated except for EFL and E for a few weeks. I can revert to e 21 and it goes away.

Distro does not patch sudo. Seems to get such you need to use the -A argument with sudo. Not sure it will invoke it normally otherwise, vs a command line prompt for such. Man page confirms the same. As you can see with script I am not using that option. Nor would it be automatic for terminal.

  -A, --askpass                 use a helper program for password prompting

Also seems to only happen with the first call to sudo in that script, not the one to sudo killall. That does not cause it to pop up. Thus it is in consistent.

@wltjr can you try putting this line: exec 0<> /dev/zero just after the shebang and see if that fixes it?

@ProhtMeyhet added on 2nd line and no change. Still pops up only on running my 99-synergyc script. The killall does not cause it to pop up.

FYI I am hitting the window X button to close the dialog. I am not entering in any password etc. I assume if it was part of normal function. Something would fail when not entering a password. It seems to know its not needed. Just the dialog thinks that it is. Not sure what the dialog is returning a status to, etc.

In T6046#98900, @wltjr wrote:

@ProhtMeyhet added on 2nd line and no change. Still pops up only on running my 99-synergyc script. The killall does not cause it to pop up.

good :-)

does /etc/X11/xinit/99-synergyc exist? sudo seems to ignore files that do not exist but are in sudoers

Yes it exists. I just added

In T6046#98903, @wltjr wrote:

Yes it exists. I just added


hmm i can't test e22 atm (still on 21.8), so i'm out of ideas. sorry.

No worries, I am ok with doing unset. But I did test it out with a missing file and seems to cause similar to happen. Seems odd to get a dialog for nothing. Also not sure it should pop up with -A not being used. Even if the env var is set. Thought you needed both, and if no SUDO_ASKPASS set, then it goes with a default or something. Either way resolved for me, can leave this open or close. Not sure if others will run into.

Also not sure it should pop up with -A not being used

That is sudo's logic. If stdin/out is not a tty it will use the askpass thing without -A. It's right there in the man page for sudo:

SUDO_ASKPASS     Specifies the path to a helper program used to read the
                 password if no terminal is available or if the -A option
                 is specified.

I stand by my original comment. ALL we do is set the env var. The rest is sudo's own logic handling. File bugs or issues with them as sudo chooses to do this by its own logic when it comes to NOPASSWD: or not. This is entirely internal to sudo. Logically if it's set to NOPASSWD: then it shouldn't ask for one irrespective of the env var, but it is.

If it isn't patching, my guess is it's a path issue. You use killall with NO path in your script (no full explicit path)... and it might be finding a different killall binary in a location that is not /usr/bin/killall which is explicit in your sudoers config ... and thus requiring a password. This has probably been failing for you for years and you just didn't know because it couldn't ask for a password as tty was not on stdin/out. That's a guess.

Just the dialog thinks that it is

The dialog doesn't think anything. it is executed by sudo if sudo thinks it needs it. All it does is dumbly ask for a password in a GUI and spew the result out to stdout that sudo takes to then auth the password. the dialog is super dumb. It thinks and knows nothing beyond "Pop up window, take password in, print what they entered to stdout. All the decisions are made by sudo - thus why I closed this and suggested you talk with them. :)

Seems it was a path issue, and it was being invoked twice. Once with messed up path. Thus getting the pop up but it also still working. Strange sudo opens a dialog for a mia file. Maybe has something to do with the pattern matching in the sudoers file. Not being a tty maybe due to it tied to graphical session. Either way resolved.