[Zope-dev] pcgi problems

[Jeff Bauer]

Quinn Dunkan wrote:
> A while back I mentioned some intermittant problems with pcgi 
> under irix, and someone else mentioned the same sort of thing.  
> (the error is 'pcgi-wrapper: Error 0  (116) unable to connect, fd=3')  
> I was wondering if the DC guys knew about this, or were interested 
> in it, or have verified its existence or cause?

Digital Creations is interested (as I am) in determining
whatever problems exist with pcgi-wrapper.

Philip Eby reported some problems earlier on Irix, but has
since moved on to fastcgi.  I don't have access to an Irix 
system, but would be happy to pursue the cause and solution 
to this problem offline.

> On the subject of pcgi, the pcgi-wrapper syntax seems rather
> clunky (written, no doubt, with a single zope process, rather
> than a bunch of 'normal' cgi processes, in mind).  It requires
> absolute paths for everything, and whenever you move one or
> create a new one it's sort of a pain.  Suppose I have:

Actually it's more of a historic relic of the shotgun
wedding between Principia and Bobo, whose union was
blessed with issue: a darling little 8 pound baby Zope.

> It would be nice to be able to shorten this to:
> #!/usr/local/apache/published/pcgi-wrapper
> PCGI_MODULE_PATH=../published/spam.py
> PCGI_DATA_DIR=../published/pcgi-data
>
> and have pcgi-wrapper intuit the rest of the values for me 
> (provided that I stick pcgi_publisher.py in pcgi-data).  What
> are the problems with this scheme?

I'm sympathetic, but fear that relative pathnames would
cause more problems than they would solve, not that anyone
could stop you, if you try. ;-)  However, in the interest 
of saying something constructive, we could discuss the
possibility of assigning a PCGI_ROOT or PCGI_BASE
directive and building a convention based on subdirectories
relative to a given root.  (I'm not especially fond of this
scheme either, but see less harm in it.)  Why not write a
quick python script to auto-generate pcgi files?

> The second problem is the pcgi-data directory.  Since pcgi 
> processes are run as the httpd user (or none or whataver), that
> user needs write access to pcgi-data.  The only solutions I see
> are either to make pcgi-data 775 and put it in the httpd group,
> or make it 777, which is the only option for normal users.  I'm
> not too keen on the idea of 777 directories, but I don't see any
> way around it besides apache's suEXEC (which is plastered with
> Big Fat Warnings).  Anyone else thought about this problem?

Your question asks what can be done about security from
within the server.  Unfortunately, there's not a very good
solution.  Certainly suEXEC has some risks, but you've
got a certain amount of risk anytime you're allowing a pool
of users to have shared access to your web server.  Our policy 
is to provide no login access of any non-admin users to the server, 
which is kept behind a bastion host firewall.  This is easier 
to enforce in a commerical environment than an educational
institution or a Zope-friendly ISP (or the Python Starship,
for that matter).  Andreas K. has some other ideas, unrelated
to pcgi, which I think are interesting.  See the archives for
further details.

> One good solution I can think of is mod_pcgi.  Is someone 
> actually working on that (or planning on working on that), or 
> are people just assuming surely someone will write it eventually?

Source code contributions are welcome. ;-)  Seriously, mod_pcgi
may make authorization more convenient, but I don't think it
significantly increases security.  However there _are_ other
reasons to consider writing a pcgi apache module:

  - performance
  - convenience

And a couple minor reasons against:

  - increased programming complexity
  - harder to debug
  - pcgi is still in the business of launching processes

I am in favor of mod_pcgi.

Digital Creations is a bit busy at the moment ... I know,
I know, you're tired of hearing it.  But I'm in the same
predicament.  I'm not sure when the next pcgi will be
released, but I'll try to get everyone's input within
the next few weeks.  Since this is all Open Source,
however, you're not required to wait on me or Digital
Creations staff to fix it. ;-)

Thank you for your comments.

Best regards,

Jeff Bauer
Rubicon, Inc.

P.S.  A minor footnote:  The pcgi-wrapper is a fairly
simple hack.  I don't find it particularly difficult to
debug problems in situ on any given Unix system, esp.
using MrCreosote.  Working remotely, however, based on
bug reports is a more iffy task.  This may not offer
much comfort to users who are not C programmers, but
I'm more than happy to provide advice (offline, unless
it's especially relevant to the other Zopeheads).
Furthermore, Digital Creations is clearly in the 
business of providing solutions to Zope problems.

they-removed-the-one-to-a-customer-limit-last-week-ly yr's ...