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

[Phillip J. Eby]

At 01:33 AM 6/12/2007 +0200, Jerome Alet wrote:
>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.

...which is why the cache location has to be readable and writable by 
every user the process will be executing as.


>It's IMHO a design problem with setuptools, which should do its best
>when permissions prevent it to run as expected.

When it doesn't have permission to write to a cache directory, it's 
game over.  Currently, there is no other way to execute a .so, .dll, 
.pyd, or other dynamic library from inside a zipfile, except for some 
GPL code that can do it on Windows (and which I can't mix with setuptools).


>For example "standard"
>Python .py files are only compiled onto the harddisk as .pyc if permissions
>permit.

This isn't an analagous situation; without unpacking the .so file, 
the driver isn't going to be loadable.


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

A patch to replace expanduser would be fine; please make sure, 
however, that it falls back to use of expanduser in the event of an error.