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.

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.

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?

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)

> 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.

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.

> 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.

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.

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

Simplified if/else chaining

Uploading here before testing on new machine (m4 was too old on previous
machine)

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.

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?

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.

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.

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?

I'll take care of it.  It needs unittests but those will be trivial.

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.

I have now added documentation to os.rst, and committed the patch as
r76550 and r76552.

Thanks for contributing it.