[Distutils] [jerome: Re: real vs effective user id]
alet at librelogiciel.com
Tue Jun 12 01:33:38 CEST 2007
On Mon, Jun 11, 2007 at 05:02:23PM -0400, Phillip J. Eby wrote:
> >So you mean that if for example another (different) module installed
> >with setuptools was imported *before* the seteuid() call, then the
> >mysqldb module import (done *after* the seteuid() call) would
> >succeed ?
> No. I'm saying that the directory for the default ResourceManager's
> cache is determined exactly once, and can't be changed thereafter for
> the effective life of the process. Thus, you must choose a location
> that is readable and writable by every user id that the process will
> be executing as, whether real or effective.
The problem is that the setuptools code doesn't fail because the
expanduser() call fails, it fails (during my import of the mysqldb
this is setuptools' code which fails) because it tries to read from or
write to a protected directory.
It's IMHO a design problem with setuptools, which should do its best
when permissions prevent it to run as expected. For example "standard"
Python .py files are only compiled onto the harddisk as .pyc if permissions
If the process is started by root, there's no way I can tell the users
of my software to make ~root/.python-eggs writable (or even readable)
by the user this app will do a seteuid call to. It's basic security stuff.
(and yes there are valid reasons why this software needs to be started
> >Then maybe setuptools should continue to work without creating/writing
> >any file in an user's .python-eggs directory if this is not allowed
> >to do so because of permissions (or different effective user).
> >Instead it fails hard. Any plan to improve this ?
> You have several options. First, setuptools can build RPMs which
> install files in the usual way. Second, you can install eggs
> containing C code as directories instead of files (using easy_install
> --always-unzip), which then avoids the need for the use of the egg
> cache. Third, you can select an appropriate cache directory, either
> with the environment variable, or programmatically.
I think you misunderstand the problem :
1 - I don't use setuptools as part of the installation of my
2 - My own software relies on third party modules which may, or
may not, be installed through setuptools. I can't know if
they are, or which options (in the ones you list above) will
be chosen by the administrators who install these third
party modules. I'm in no position to dictate what admins
have to do with regard to software I didn't wrote (mysqldb
for example) or that I don't even use (setuptools).
3 - My own software, which runs perfectly for hundreds of customers,
failed miserably for one of them because he chose to install a
database driver with setuptools, for the reasons explained
previously. It could have been a different module, and happen
at a different import statement in my code (the app is made of
several command line tools).
4 - My code basically does :
groupid = 25
userid = 33
and so can revert to being root again when needed by calling :
I know this is not entirely safe from a security point of view,
but this is to prevent accidents, not crackers.
Is this a bug in my code ? I don't think so, it's valid code.
5 - Why would I need to put ugly hacks (environment variable)
in my own code ? As seen earlier this probably can't be done
safely since the directory will be evaluated only once (I could
always set it to /tmp/username/.python-eggs to mitigate the
problem, but this sucks big time IMHO).
6 - Besides not having to rewrite the expanduser() method, is
there a valid reason why setuptools checks with the real
user's home directory instead of with the effective one ?
If not, then I propose to write the patch. If yes, then
which one ?
Any comment ?
More information about the Distutils-SIG