It should be easier to write network servers and setuid programs in
python.  One of the troublesome issues is that the semantics of the
setuid/getuid-related calls are quite complicated.

There are two papers on this subject that form the background of this
feature request:
http://www.cs.berkeley.edu/~daw/papers/setuid-usenix02.pdf
http://www.cs.berkeley.edu/~daw/papers/setuid-login08b.pdf

In general, then, the end goal is a safe (portable, secure) way to drop
privileges either temporarily or permanently.

Wagner et. al. have proposed a decent interface, but it's unclear to me
where it should be implemented.

Furthermore, it makes use of the getresuid/setresuid calls (among many
others), which don't appear from their manpages to be standardized by
POSIX, but are available in most modern Unix OSes.  So this leaves me
with two questions; have these functions been standardized, and if not,
where should they be implemented?

I'm willing to do the coding, but need some guidance on where to put the
code.

The posixmodule.c seems to have a lot of really complex CPP logic about
what chunks to compile.  If the target is to put the code there, I would
have to be guessing - next to the HAVE_GETEUID looks promising.

But wouldn't it be better to have the configure script check for the
presence of e.g. getresuid and compile it iff it finds it?  So that
sounds like some work with the autoconf script...

The routines necessary for implementing Wagner's API for dropping
privileges are:

sysconf function: available in os module
_SC_NGROUPS_MAX constant: unsure
abort function: available in os module
getresuid function: needs implementing[1]
getresgid function: needs implementing[1]

[1] Not POSIX but available on Linux, HP/UX, FreeBSD, OpenBSD,
DragonFlyBSD.  Not available on Solaris, AIX, NetBSD, OSX, cygwin.

Since Wagner points out that the non-standard function calls actually
have clearer/better semantics, perhaps the way to do all this is in its
own module, instead of trying to shove it into an existing module..

Maybe this should just be a third-party module for the time being?  That
removes the question of which stdlib module to add it to for now.  Plus,
since it's not just a straightforward platform API wrapper, it probably
merits separate distribution to see what adoption is like and what the
Python community response is.

If the logic is going to be built on top of the APIs that are already
there, I agree that it would be best to implement this as a separate
module, and upload it to pypi.python.org.

Closing as "won't fix".

It would still be nice to have the currently unimplemented platform
wrappers added to the standard library, though.  For example, as solinym
pointed out, getresuid and getresgid are not currently wrapped at all. 
There may be other low-level APIs which may be missing as well.

> It would still be nice to have the currently unimplemented platform
> wrappers added to the standard library, though.  For example, as solinym
> pointed out, getresuid and getresgid are not currently wrapped at all. 
> There may be other low-level APIs which may be missing as well.

Ah, ok. A patch for to add these specifically would be easy to add;
contributions are welcome.

This is my first stab at creating a "privilege" module that implements
the API suggested in the second aforementioned paper.

It is syntactically correct but has some TODO items in it that must be
completed before it will work.

Any suggestions on this code would be greatly appreciated.

On Fri, Aug 21, 2009 at 08:42:43PM +0000, Martin v. L??wis wrote:
> 
> Martin v. L??wis <martin@v.loewis.de> added the comment:
> 
> > It would still be nice to have the currently unimplemented platform
> > wrappers added to the standard library, though.  For example, as solinym
> > pointed out, getresuid and getresgid are not currently wrapped at all. 
> > There may be other low-level APIs which may be missing as well.
> 
> Ah, ok. A patch for to add these specifically would be easy to add;
> contributions are welcome.

I kind of have two bugs going for the same thing; one is 6758 the other is 6508.

I've posted code that implements the calls using ctypes to
{get,set}res{uid,gid} in issue6758.  It's not quite done.

With regard to putting these calls into the standard library, I'm not
sure where they should go.  If I put them in os, which maps to
posixmodule.c, then I'll be adding non-POSIX calls to something
seemingly only for POSIX calls.

Also the code in there has a lot of conditional CPP logic and
interactions with the configure script.  So that could be a difficult
task to just jump into, since it has been a while since I dealt with
autoconf.

I really would like these routines exposed, but I don't know the best
way to do it and coudl use some guidance.
-- 
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.

I hope you'll also write some unit tests for privilege.py (actually, I
hope you'll do test driven development on it).