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