FS#45735 - [sudo] 1.8.14.p2-1 - execute command without password only works from terminal

Attached to Project: Arch Linux
Opened by nerdix (nerdix) - Tuesday, 21 July 2015, 18:07 GMT
Last edited by Jan Alexander Steffens (heftig) - Wednesday, 22 July 2015, 12:02 GMT
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Evangelos Foutras (foutrelis)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

Description: execting sudo /usr/bin/systemctl suspend does not work anymore when not run inside a terminal.


Additional info:
* 1.8.14.p2-1

/etc/sudoers

%power ALL=(ALL) NOPASSWD:/usr/bin/systemctl suspend

~/.fluxbox/menu

[exec] (Supend) {sudo /usr/bin/systemctl suspend}

my user is in group power and this was working with sudo 1.8.14.p1-1 and prior versions, now I have to run avove command from an xterm to get it working:


[exec] (Supend) {xterm -e 'sudo /usr/bin/systemctl suspend'}

same if invoked from fbrun

I tried to put the following in /etc/sudoers

Defaults !requiretty

but no luck.

Downgrading to sudo 1.8.14.p1-1 fixed it.


If no bug please explain how to get back old behaviour.




Steps to reproduce:
This task depends upon

Closed by  Jan Alexander Steffens (heftig)
Wednesday, 22 July 2015, 12:02 GMT
Reason for closing:  Fixed
Additional comments about closing:  sudo 1.8.14p2-2
Comment by nerdix (nerdix) - Tuesday, 21 July 2015, 18:17 GMT
gksudo also does not work anymore with nopasswd option
Comment by Jason R. McNeil (jasonrm) - Tuesday, 21 July 2015, 18:43 GMT
I'm not quite sure if it's the exact same issue that I'm running into, but the failure mode is the same.

-- error message --
sudo: main: unable to allocate memory

-- steps to reproduce --

TMP_SYS='tmp_sys'
mkdir ${TMP_SYS}
pacstrap -c -d ${TMP_SYS} base sudo

systemd-nspawn --quiet --directory=${TMP_SYS} whoami

systemd-nspawn --quiet --directory=${TMP_SYS} sudo -u nobody whoami
Comment by P.H. (Vain) - Tuesday, 21 July 2015, 19:41 GMT
Since there have only been two commits since 1.8.14.p1 -- one of which appears to be unrelated --, the offending commit is likely to be this one:

http://www.sudo.ws/repos/sudo/rev/c58cce92d5e0

Simply reverting that commit fixes the issue for me. It's a rather big commit, so I don't have a patch ready... I'll report this upstream tomorrow evening (but I guess someone else will beat me to it ;-)).
Comment by Lex Black (TrialnError) - Tuesday, 21 July 2015, 21:14 GMT
Upstream bug report (I suppose)
http://bugzilla.sudo.ws/show_bug.cgi?id=706
Comment by Jens Adam (byte) - Wednesday, 22 July 2015, 01:56 GMT
@foutrelis: for the future, even if the upstream changelog looks absolutely harmless, we have [testing] for a reason ... and 2 minutes before moving to [core] is a little bit too quick for proper testing;-)
Comment by nerdix (nerdix) - Wednesday, 22 July 2015, 06:17 GMT
@byte
Full ack, especially since this is a core package

How do you get the error message about "unable to allocate memory"? I can't find anything related in my logs. When trying to trace it, it works because invoked from a tty/pty...
So how do I test if my problem is related to the "unable to allocate memory" error?
gksudo does not work at all with this new sudo package...
Comment by Lex Black (TrialnError) - Wednesday, 22 July 2015, 12:01 GMT
  • Field changed: Percent Complete (100% → 0%)
Not a real request, but couldn't add a notice otherwise. The Patch could have a typo. See the line https://projects.archlinux.org/svntogit/packages.git/tree/trunk/no-tty.patch?h=packages/sudo#n50 Upstream bugreport asks the same question
Comment by Jan Alexander Steffens (heftig) - Wednesday, 22 July 2015, 12:02 GMT
The typo is in code only used on Solaris.

Loading...