expose setresuid

[solinym]

BPO	6508
Nosy	@loewis, @gpshead, @amauryfa, @davidmalcolm
Files	foo.txt: patch to add {get,set}res{uid,gid} functionality foo.txt: diff from Python 2.6.1 setresuid.patch res.patch: complete patch for making {set,get}res{uid,gid} available under os/posix module issue6508-gps01.diff

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/gpshead'
closed_at = <Date 2009-11-27.14:13:08.935>
created_at = <Date 2009-07-17.22:25:31.641>
labels = ['extension-modules', 'type-feature']
title = 'expose setresuid'
updated_at = <Date 2009-11-27.14:13:08.934>
user = 'https://bugs.python.org/solinym'

bugs.python.org fields:

activity = <Date 2009-11-27.14:13:08.934>
actor = 'loewis'
assignee = 'gregory.p.smith'
closed = True
closed_date = <Date 2009-11-27.14:13:08.935>
closer = 'loewis'
components = ['Extension Modules']
creation = <Date 2009-07-17.22:25:31.641>
creator = 'solinym'
dependencies = []
files = ['14903', '14918', '14919', '14923', '15297']
hgrepos = []
issue_num = 6508
keywords = ['patch']
message_count = 18.0
messages = ['90642', '90645', '91852', '91855', '91858', '92720', '92726', '92744', '92745', '92788', '92790', '92813', '92830', '92831', '94997', '94999', '95062', '95770']
nosy_count = 5.0
nosy_names = ['loewis', 'gregory.p.smith', 'amaury.forgeotdarc', 'solinym', 'dmalcolm']
pr_nums = []
priority = 'normal'
resolution = 'accepted'
stage = 'test needed'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue6508'
versions = ['Python 2.7', 'Python 3.2']

[solinym]

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.

[solinym]

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.

[solinym]

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?

[amauryfa]

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)

[loewis]

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.

[solinym]

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.

[davidmalcolm]

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.

[loewis]

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.

[loewis]

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 bpo-6873

[solinym]

Simplified if/else chaining

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

[solinym]

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.

[loewis]

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?

[solinym]

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.

[solinym]

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.