-
Notifications
You must be signed in to change notification settings - Fork 476
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot run setuid commands like sudo with spawn #104
Comments
can you please try instead: |
And also:
|
I see the problem, it is a regression of my recent "which" change. It does not "appear executable" ? ---s--x--x. 1 root root 123832 Feb 22 2013 /usr/bin/sudo @cchiu1: Use this as a workaround until we can release a fix please!
|
So we have learned you may execute files that you may not read !
|
Previously, misinterpreted that os.access(file, X_OK) always returns True on Solaris. Yes, but only for the uid of 0. Python issue #13706 closed "not a bug" reads to "just use os.stat()", so we went to great lengths to do so quite exhaustively. But this is wrong -- *only* when root, should we check the file modes -- os.access of X_OK works perfectly fine for non-root users. And, we should only check if any of the executable bits are set. Alas, it is true, you may execute that which you may not read -- because as root, you can always read it anyway. Verified similar solution in NetBSD test.c (/bin/test), OpenBSD ksh for its built-in test, and what FreeBSD/Darwin for their implementation of which.c.
It appears there was a regression in pexpect 3.3 that broke various sudo commands on centos See: pexpect/pexpect#104 For now we will just prevent it from loading 3.3 in our requirements.txt but we may need to fix this better in the future
A regressions was introduced in pexpect version 3.3 which causes problems running commands under sudo on certain platforms. See: pexpect/pexpect#104 for more information. This regression has been resolved but not yet released. Change-Id: I09de87f04595a9ee7e6ce50724add8593215a043
Project: openstack/requirements 162542e1917de7cbb52b89ba4feec59f958684a0 Avoid using pexpect version 3.3 A regressions was introduced in pexpect version 3.3 which causes problems running commands under sudo on certain platforms. See: pexpect/pexpect#104 for more information. This regression has been resolved but not yet released. Change-Id: I09de87f04595a9ee7e6ce50724add8593215a043
Project: openstack/requirements 162542e1917de7cbb52b89ba4feec59f958684a0 Avoid using pexpect version 3.3 A regressions was introduced in pexpect version 3.3 which causes problems running commands under sudo on certain platforms. See: pexpect/pexpect#104 for more information. This regression has been resolved but not yet released. Change-Id: I09de87f04595a9ee7e6ce50724add8593215a043
Here's an alternative workaround to get pexpect.which, original_which = (lambda filename: '/usr/bin/sudo' if filename in ('sudo', '/usr/bin/sudo') else original_which(filename),
pexpect.which) |
Fixed in upcoming 4.0 release by #106. #106 was earmarked for release 3.4 which was meant to be release but did not happen for some unfortunate reason, submitted PR #257 to avoid such release confusion. Hope to have 4.0 out soon, just awaiting @takluyver's approval of pending PR's and his publish ok. |
I installed the pexpect on Python 2.7.7 and CentOS 6.5.
On a terminal, I can run "sudo ls".
However, if I put "pexpect.spawn('sudo ls')" in a Python script, I always get the exception "The command was not found or was not executable: sudo.".
I confirmed that "sudo" is in /usr/bin/.
How do I make it executable for "pexpect"?
The text was updated successfully, but these errors were encountered: