[Distutils] entry point for new installations?

[Phillip J. Eby]

At 05:26 PM 3/20/2006 -0500, Kevin Dangoor wrote:
>On 3/20/06, Phillip J. Eby <pje at telecommunity.com> wrote:
> > An entry point won't really help you much here, because it would have to
> > know how to perform this notification.  Presumably, it would either have to
> > talk to a socket or modify a file somewhere.
>
>The egg that has that entry point would have to know how to find its
>configuration file to know what to notify, yes.

configuration file*s* - you might have multiple copies of something.  And 
Python packages don't really (i.e. shouldn't) own configuration files of 
their own.


> > However, if you're going to have to monitor for file changes anyway, then
> > you might as well just monitor sys.path directories for new .egg files, or
> > monitor changes to easy-install.pth files.
>
>My thought was that no file monitoring would be required. easy_install
>would keep track of the eggs it installed and then pass that list
>along to everything that defines that entry point.

Yeah, except that your approach effectively requires building an egg for 
every *instance* of every app on the box, and also requires you to have a 
privileged process running an individual user's code.

I know that you probably have a rather more restricted deployment scenario 
in mind, I'm just pointing out that the approach you were proposing falls 
apart as soon as multiple instances or users with different privileges are 
involved.  (Heck, even my SIGHUP approach has some issues with that, since 
a high-privilege installer could then be tricked into signalling some other 
process.)


> > The only other thing I can think of that would work is if you had server
> > processes write their process IDs some place, and then the hypothetical
> > entry point could send them SIGHUPs or something.  But monitoring
> > file/directory changes is a bit more cross-platform, doesn't require adding
> > any entry point code, is probably part of existing reload code, and doesn't
> > require a pidfile arena, with all the associated permissions and cleanup
> > headaches thereof.
>
>The entry point is probably a premature optimization. File
>modification time lookups are pretty cheap. And, if it's only watching
>easy-install.pth, that would be dirt cheap.

Yeah, and this latter exchange has convinced me that it's the only simple 
way to avoid privilege escalation attacks.  That is, it doesn't require 
low/medium-privilege server processes to be able to write stuff (like entry 
point code, pids, or configuration files) that gets read or executed (or 
otherwise relied upon) by the high-privilege installation process.