[Distutils] [jerome: Re: real vs effective user id]

Jerome Alet 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
as root)

> >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
      own software.
  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 ?      


Jerome Alet

More information about the Distutils-SIG mailing list