This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: expose setresuid
Type: enhancement Stage: test needed
Components: Extension Modules Versions: Python 3.2, Python 2.7
process
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: gregory.p.smith Nosy List: amaury.forgeotdarc, dmalcolm, gregory.p.smith, loewis, solinym
Priority: normal Keywords: patch

Created on 2009-07-17 22:25 by solinym, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
foo.txt solinym, 2009-09-16 21:35 patch to add {get,set}res{uid,gid} functionality
foo.txt solinym, 2009-09-17 18:03 diff from Python 2.6.1
setresuid.patch solinym, 2009-09-17 19:05
res.patch solinym, 2009-09-18 16:31 complete patch for making {set,get}res{uid,gid} available under os/posix module
issue6508-gps01.diff gregory.p.smith, 2009-11-09 08:03
Messages (18)
msg90642 - (view) Author: Travis H. (solinym) Date: 2009-07-17 22:25
Python should expose setresuid in the same module that exposes setuid.

The reason why is complicated, but is best explained here:

http://www.eecs.berkeley.edu/~daw/papers/setuid-usenix02.pdf

I might work on a patch to implement this.
msg90645 - (view) Author: Travis H. (solinym) Date: 2009-07-17 22:47
should also expose setresgid for same reason.

Paper also defines a higher-level API in section 8.2.1 that would
probably be worth implementing.
msg91852 - (view) Author: Travis H. (solinym) Date: 2009-08-22 03:02
Where would be the best place to put these non-POSIX calls?

I looked at posixmodule.c and it's a mess; much conditional CPP logic
governing what gets compiled, not clear where I should add something
like this there - if I should at all, since these routines are not POSIX
routines.

Perhaps there should be a module called Unix or something?

Also, knowing whether the functions were avaiable at compile time would
be tricky; some Unix OSes have them and others don't.  It sounds like a
job for autoconf to define HAVE_SETRESUID and other CPP definitions like
that so we can compile cleanly and portably...

Thoughts?
msg91855 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2009-08-22 07:07
Yes, just put it near the numerous set_XXXuid functions, protected with a 
HAVE_SETRESUID macro (you will have to modify configure.in as well)
msg91858 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-08-22 07:48
> Where would be the best place to put these non-POSIX calls?
> 
> I looked at posixmodule.c and it's a mess; much conditional CPP logic
> governing what gets compiled, not clear where I should add something
> like this there - if I should at all, since these routines are not POSIX
> routines.

Don't worry about that - the POSIX module is the right place, despite
it's name.

> Perhaps there should be a module called Unix or something?

That wouldn't reduce the need to remove CPP logic. I personally don't
find that CPP logic very messy - most of it is fairly clear (perhaps
with popen being the exception).

> Also, knowing whether the functions were avaiable at compile time would
> be tricky; some Unix OSes have them and others don't.

I don't understand. When you compile for a specific Unix, it either has
them or not, right? So you *can* test at compile time, and easily so
(the same way it test for about 20 other functions).

> It sounds like a
> job for autoconf to define HAVE_SETRESUID and other CPP definitions like
> that so we can compile cleanly and portably...

Correct - you need to change configure.in as well.
msg92720 - (view) Author: Travis H. (solinym) Date: 2009-09-16 21:35
I have coded up a first draft at implemented {get,set}res{gid,uid}
functions.  This completes the exposure of the user and group setting
functions, and enables python programmers to be able to safely drop
privileges, for example when running network daemons as root that need
to drop down to user privileges, or writing a setuid program which needs
to do the same.

I cannot test this in my current environment because I'm stuck with Red
Hat and it does not have a recent enough automake to re-create configure
from configure.in.
msg92726 - (view) Author: Dave Malcolm (dmalcolm) (Python committer) Date: 2009-09-16 22:23
> I cannot test this in my current environment because I'm stuck with Red
> Hat and it does not have a recent enough automake to re-create configure
> from configure.in.

FWIW, it may be an _autoconf_ version issue; I'm able to recreate a
"configure" from Python's "configure.in" on my RHEL5 box by downloading
autoconf-2.61 from http://ftp.gnu.org/gnu/autoconf/
installing it to /usr/local (with ./configure ; make; sudo make install)
then invoking /usr/local/bin/autoconf in the root of an SVN checkout of
python.   Hope this is helpful.
msg92744 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-09-17 08:12
Please do try this out on your system. Installing autoconf locally is 
really not difficult: download 2.61, then do

./configure --prefix=$HOME/ac261
make
make install

This will give you $HOME/ac261/bin/auto{conf|header}; automake is not 
needed for Python.
msg92745 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-09-17 08:17
Your patch looks right, although I have a few style issues:
- the if chaining looks complicated: we don't usually have an else when 
the if returns
- make sure you use tabs consistently with the rest of the file
- it may be better to use uid_t where appropriate, see issue6873
msg92788 - (view) Author: Travis H. (solinym) Date: 2009-09-17 18:03
Simplified if/else chaining

Uploading here before testing on new machine (m4 was too old on previous
machine)
msg92790 - (view) Author: Travis H. (solinym) Date: 2009-09-17 19:05
I applied the same patch to Python 2.6.2 and believe that I got the
tab/space situation worked out so that it's consistent with the rest of
posixmodule.c

I also executed autoconf to convert configure.in to configure, and
judging by the config.log, it is testing for and finding setresuid and
friends.  It is also defining HAVE_SETRESUID to 1 as expected.  However,
when I execute this python and import os (or posix), it says that module
doesn't have the setresuid attribute.

I ran "strings" on libpython2.6a and found that it has the strings
"setuid" and "setreuid" as expected, but not my "setresuid".

Does anyone have any idea why this might be?  I'm trying hard to get
this into python but I'm not an expert on how the build works.
msg92813 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-09-18 07:44
Your patch looks good (except that in getresuid, you seem to be missing 
return). I have no clue why it doesn't work; I'll see whether I can try it 
out on Linux within the next few weeks.

The one puzzling detail is that you don't include a patch to 
pyconfig.h.in: did you run autoheader?
msg92830 - (view) Author: Travis H. (solinym) Date: 2009-09-18 16:31
This patch fixes a number of typos in the original and, to my knowledge,
is now complete.

I have tested this manually and confirmed that it works.  I would start
as root, setresuid/gid to some non-root uid/gids, getresuid/gid to test
those functions, and follow it up with os.system("id") to check using an
outside utility.
msg92831 - (view) Author: Travis H. (solinym) Date: 2009-09-18 16:33
On Fri, Sep 18, 2009 at 07:44:56AM +0000, Martin v. L??wis wrote:
> 
> Your patch looks good (except that in getresuid, you seem to be missing 
> return). I have no clue why it doesn't work; I'll see whether I can try it 
> out on Linux within the next few weeks.

I am testing it out now on a more up-to-date machine.

> The one puzzling detail is that you don't include a patch to 
> pyconfig.h.in: did you run autoheader?

No, I did not - it has been a long time since I was familiar with
autotools - and that was why there was no access to these functions
when I compiled before.

I've now got a complete, tested patch up on bugs.python.org
-- 
Obama Nation | My emails do not have attachments; it's a digital signature
that your mail program doesn't understand. | http://www.subspacefield.org/~travis/ 
If you are a spammer, please email john@subspacefield.org to get blacklisted.
msg94997 - (view) Author: Travis H. (solinym) Date: 2009-11-06 20:17
So this patch is done and tested, but no movement on it since 18
September.  Is there anything I can do to help move this along towards
integration?
msg94999 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2009-11-06 21:03
I'll take care of it.  It needs unittests but those will be trivial.
msg95062 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2009-11-09 08:03
Attaching an updated patch that includes unittests.

I also changed the set functions to take input as long's instead of int's 
as that is more likely to fit within a uid_t and forced the return values 
on the get's to fit within a long and used Py_BuildValue() to handle 
memory errors and such that could happen while allocating the ints and 
tuple rather than PyTuple_Pack.

Remaining work: os module documentation.
msg95770 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-11-27 14:13
I have now added documentation to os.rst, and committed the patch as
r76550 and r76552.

Thanks for contributing it.
History
Date User Action Args
2022-04-11 14:56:51adminsetgithub: 50757
2009-11-27 14:13:08loewissetstatus: open -> closed
resolution: accepted
messages: + msg95770
2009-11-09 08:03:35gregory.p.smithsetfiles: + issue6508-gps01.diff

messages: + msg95062
2009-11-06 21:03:59gregory.p.smithsetpriority: normal
versions: + Python 2.7, Python 3.2, - Python 2.6
messages: + msg94999

assignee: gregory.p.smith
type: enhancement
stage: test needed
2009-11-06 20:17:23solinymsetmessages: + msg94997
2009-09-18 16:33:25solinymsetmessages: + msg92831
2009-09-18 16:31:53solinymsetfiles: + res.patch

messages: + msg92830
2009-09-18 07:44:54loewissetmessages: + msg92813
2009-09-17 19:05:15solinymsetfiles: + setresuid.patch
keywords: + patch
messages: + msg92790
2009-09-17 18:03:14solinymsetfiles: + foo.txt

messages: + msg92788
2009-09-17 08:17:52loewissetmessages: + msg92745
2009-09-17 08:12:44loewissetmessages: + msg92744
2009-09-16 22:23:04dmalcolmsetnosy: + dmalcolm
messages: + msg92726
2009-09-16 21:35:57solinymsetfiles: + foo.txt

messages: + msg92720
versions: + Python 2.6, - Python 3.2
2009-08-27 19:04:43gregory.p.smithsetnosy: + gregory.p.smith
2009-08-22 07:48:50loewissetmessages: + msg91858
2009-08-22 07:07:25amaury.forgeotdarcsetnosy: + amaury.forgeotdarc
messages: + msg91855
2009-08-22 03:03:00solinymsetmessages: + msg91852
2009-08-21 20:44:06loewissetmessages: - msg91844
2009-08-21 20:43:43loewissetnosy: + loewis
messages: + msg91844
2009-07-17 22:47:21solinymsetmessages: + msg90645
2009-07-17 22:25:31solinymcreate