Hi, Does anyone out there already have a pcgi-wrapper that is hardcoded to run directly instead of through a script like Zope.cgi? I want to do this so that I can safely run it setuid. If no one has such a beast, I'll muck about in the C code and see if I can patch it. (I haven't done anything in C since '96... the thought of going back is frightening :) Kevin -- Kevin Dangoor kid@ans.net / 734-214-7349
Kevin Dangoor wrote:
Does anyone out there already have a pcgi-wrapper that is hardcoded to run directly instead of through a script like Zope.cgi? I want to do this so that I can safely run it setuid. If no one has such a beast, I'll muck about in the C code and see if I can patch it. (I haven't done anything in C since '96... the thought of going back is frightening :)
I'm not sure I understand how this increases security, but if your goal is to hardwire all your Zope settings into a binary, it's not difficult to do. Although maintaining it will be a drag. If you're going to go down this path, you might as well write a Python shell script to automate the process, i.e. have it read in Zope.cgi to create a header file that is then is compiled to your binary (Please call it something other than pcgi-wrapper.) This should all be probably placed in a Makefile, with Zope.cgi as your dependency. With queasy regards, Jeff Bauer Rubicon, Inc.
On Tue, Feb 02, 1999 at 09:31:07PM -0600, Jeff Bauer wrote: ,----- | Kevin Dangoor wrote: | > Does anyone out there already have a pcgi-wrapper that is | > hardcoded to run directly instead of through a script like Zope.cgi? | > I want to do this so that I can safely run it setuid. If no one | > has such a beast, I'll muck about in the C code and see if I can | > patch it. (I haven't done anything in C since '96... the thought | > of going back is frightening :) | | I'm not sure I understand how this increases security, but if your | goal is to hardwire all your Zope settings into a binary, it's | not difficult to do. Here's my thinking... I'm running in a shared hosting environment. In order to prevent everyone on the same machine as my server from being able to write to my var directory, I would like to be able to run pcgi as setuid. However, the way it works now would allow people to run arbitrary programs under my user ID. It's not a huge exposure, but it can be eliminated. | Although maintaining it will be a drag. | If you're going to go down this path, you might as well | write a Python shell script to automate the process, i.e. | have it read in Zope.cgi to create a header file that is | then is compiled to your binary (Please call it something | other than pcgi-wrapper.) This should all be probably | placed in a Makefile, with Zope.cgi as your dependency. My thinking was something like this: Make a #define for hardcoding. If it's there, the parsing code goes away and the necessary variables are filled in by other #defines in the header. That way, it is easy to choose which way to do it and easy to set it up. Yes, maintaining it still requires recompiling the program, but I think the improved security is worth it. Unless there's something I've missed, I think this is the most secure way for one to run Zope in a shared hosting environment... Kevin | | With queasy regards, | | Jeff Bauer | Rubicon, Inc. | `----- -- Kevin Dangoor UUnet Technologies kid@ans.net / 734-214-7349
At 09:44 AM 2/3/99 -0500, Kevin Dangoor wrote:
Unless there's something I've missed, I think this is the most secure way for one to run Zope in a shared hosting environment...
Only if your shared hosting environment doesn't give every domain its own Unix user ID and executes CGI's under that ID... :) In any case, it's not pcgi-wrapper that really needs to be setuid, it's Zope itself. So you need to either be on a platform that supports setuid scripts, or write a C wrapper that wraps the server-side Zope, not the PCGI client.
On Wed, Feb 03, 1999 at 12:18:04PM -0500, Phillip J. Eby wrote: ,----- | At 09:44 AM 2/3/99 -0500, Kevin Dangoor wrote: | > | >Unless there's something I've missed, I think this is the most secure way | >for one to run Zope in a shared hosting environment... | | Only if your shared hosting environment doesn't give every domain its own | Unix user ID and executes CGI's under that ID... :) Hmm... If the hosting company doesn't give you your own Unix uid, I don't think there's any way to prevent people from getting at your data... | | In any case, it's not pcgi-wrapper that really needs to be setuid, it's | Zope itself. So you need to either be on a platform that supports setuid | scripts, or write a C wrapper that wraps the server-side Zope, not the PCGI | client. But pcgi *is* the wrapper, right? pcgi starts up Zope when it isn't running and then passes requests to it after that. So, if pcgi is running setuid, the it will start up Zope under my uid as well. (I have tried this already, and it works. Zope runs as my user id if I chmod u+s pcgi-wrapper.) `----- Kevin -- Kevin Dangoor UUnet Technologies kid@ans.net / 734-214-7349
At 01:41 PM 2/3/99 -0500, Kevin Dangoor wrote:
On Wed, Feb 03, 1999 at 12:18:04PM -0500, Phillip J. Eby wrote: ,----- | | Only if your shared hosting environment doesn't give every domain its own | Unix user ID and executes CGI's under that ID... :)
Hmm... If the hosting company doesn't give you your own Unix uid, I don't think there's any way to prevent people from getting at your data...
Oops, that was unclear. I meant to say that if your host gives you your own ID, *and* executes CGI under that ID, then you have nothing else to do except keep permissions straight.
But pcgi *is* the wrapper, right? pcgi starts up Zope when it isn't running and then passes requests to it after that. So, if pcgi is running setuid, the it will start up Zope under my uid as well. (I have tried this already, and it works. Zope runs as my user id if I chmod u+s pcgi-wrapper.)
True, but my understanding is that PCGI is moving away from being the process management part of the system. This may be especially true if there ends up being a PCGI handler in ZServer, or you're running ZServer on a different machine than the web server.
On Wed, Feb 03, 1999 at 02:04:10PM -0500, Phillip J. Eby wrote: ,----- | At 01:41 PM 2/3/99 -0500, Kevin Dangoor wrote: | >On Wed, Feb 03, 1999 at 12:18:04PM -0500, Phillip J. Eby wrote: | >,----- | >| | >| Only if your shared hosting environment doesn't give every domain its own | >| Unix user ID and executes CGI's under that ID... :) | > | >Hmm... If the hosting company doesn't give you your own Unix uid, I don't | >think there's any way to prevent people from getting at your data... | | Oops, that was unclear. I meant to say that if your host gives you your | own ID, *and* executes CGI under that ID, then you have nothing else to do | except keep permissions straight. Ahh! That's ideal! Does someone out there set it up like that? | >But pcgi *is* the wrapper, right? pcgi starts up Zope when it isn't | running and then passes requests to it after that. So, if pcgi is running | setuid, the it will start up Zope under my uid as well. (I have tried this | already, and it works. Zope runs as my user id if I chmod u+s pcgi-wrapper.) | | True, but my understanding is that PCGI is moving away from being the | process management part of the system. This may be especially true if | there ends up being a PCGI handler in ZServer, or you're running ZServer on | a different machine than the web server. `----- I think the potential is great that there will be people out there who want to use Zope on a server they don't control... and it seems like PCGI is the most efficient way to do that. I think there will be many scenarios in which PCGI is not necessary (or even desirable). However, for people trying to serve up their web pages for $30/month (or whatever) PCGI seems like the best route... Kevin -- Kevin Dangoor kid@ans.net / 734-214-7349
At 02:50 PM 2/3/99 -0500, Kevin Dangoor wrote:
On Wed, Feb 03, 1999 at 02:04:10PM -0500, Phillip J. Eby wrote: ,----- | Oops, that was unclear. I meant to say that if your host gives you your | own ID, *and* executes CGI under that ID, then you have nothing else to do | except keep permissions straight.
Ahh! That's ideal! Does someone out there set it up like that?
Hiway, RapidSite, BellSouth, BellAtlantic, Ameritech, GTE (when they launch gte-hosting.net or .com or whatever it is), as well as numerous private-label hosting providers who are affiliated with one of the above companies but not disclosing their relationship. If you're curious whether a particular hosting service is on the platform that supports this, just check to see if the server is "Rapidsite/Apa" using the NetCraft "What server does that site run?" page. The "Rapidsite/Apa" server type is the fourth most popular (by domains served) web server on the 'net, right after vanilla Apache, IIS, and Netscape Enterprise. Its current market share is about half that of NS Enterprise, with over 86,000 to Netscape's 171,000. Given that there are no real environment standards for shared hosting with other server types, RS/Apa is arguably *the* dominant shared hosting platform in existence right now, if you consider the platform to be a combination of the server, the installed software, directory structures, hardware configurations, user control panel, etc.
I think the potential is great that there will be people out there who want to use Zope on a server they don't control... and it seems like PCGI is the most efficient way to do that. I think there will be many scenarios in which PCGI is not necessary (or even desirable). However, for people trying to serve up their web pages for $30/month (or whatever) PCGI seems like the best route...
Except for the RS/Apa platform, where PCGI presents process-start problems that FastCGI doesn't. On the RS/Apa platform, the cgi-fcgi wrapper is available, and all CGI's execute as the correct user ID to begin with, so the need for a setuid wrapper is eliminated. And some hosting brands that use the RS/Apa platform offer hosting with CGI for as little as $25/month. Now all I've got to do is get the engineers and sysadmins for the RS/Apa platform to approve Zope as a supported LRP on the platform... but that's another story. :)
On Wed, 3 Feb 1999, Phillip J. Eby wrote:
At 02:50 PM 2/3/99 -0500, Kevin Dangoor wrote:
On Wed, Feb 03, 1999 at 02:04:10PM -0500, Phillip J. Eby wrote: ,----- | Oops, that was unclear. I meant to say that if your host gives you your | own ID, *and* executes CGI under that ID, then you have nothing else to do | except keep permissions straight.
Ahh! That's ideal! Does someone out there set it up like that?
Hiway, RapidSite, BellSouth, BellAtlantic, Ameritech, GTE (when they launch gte-hosting.net or .com or whatever it is), as well as numerous private-label hosting providers who are affiliated with one of the above companies but not disclosing their relationship. If you're curious whether a particular hosting service is on the platform that supports this, just check to see if the server is "Rapidsite/Apa" using the NetCraft "What server does that site run?" page.
The "Rapidsite/Apa" server type is the fourth most popular (by domains served) web server on the 'net, right after vanilla Apache, IIS, and Netscape Enterprise. Its current market share is about half that of NS Enterprise, with over 86,000 to Netscape's 171,000. Given that there are no real environment standards for shared hosting with other server types, RS/Apa is arguably *the* dominant shared hosting platform in existence right now, if you consider the platform to be a combination of the server, the installed software, directory structures, hardware configurations, user control panel, etc. Actually, it's quite easy to setup with Apache if suexec was included in the compilation: It's just one directive in <VirtualHost>, so I'd consider Apache as shared as one get :)
The problem is, that setting su-exec and understanding it's operation (as it's extremly security sensitive) is not trivial, so services with lower quality standards seem to ignore this configuration.
Except for the RS/Apa platform, where PCGI presents process-start problems that FastCGI doesn't. On the RS/Apa platform, the cgi-fcgi wrapper is available, and all CGI's execute as the correct user ID to begin with, so the need for a setuid wrapper is eliminated. And some hosting brands that use the RS/Apa platform offer hosting with CGI for as little as $25/month. Actually, as a sysadmin, I've noticed even a less fascinating thing about Bobo. (So I presume it applies to Zope too.) The processes my BoboHTTPServer create seem to be in the 2MB data size range for the basic stuff. Considering that this is NOT shared, as it is mostly data from the kernel perspective (I'm considering Linux here, but it's a general problem), it can rather quickly add up.
Now this doesn't sound much, but compared to Apache where the memory foot print is in the area of 2-3MB, and doesn't grow significantly if you have many web servers, this can be a problem, especially if some ISP starts to offer Zope service without considering the impact upon the hardware.
Now all I've got to do is get the engineers and sysadmins for the RS/Apa So what is this RS/Apa platform? platform to approve Zope as a supported LRP on the platform... but that's another story. :)
Andreas -- Win95: n., A huge annoying boot virus that causes random spontaneous system crashes, usually just before saving a massive project. Easily cured by UNIX. See also MS-DOS, IBM-DOS, DR-DOS, Win 3.x, Win98.
At 12:52 AM 2/4/99 +0100, Andreas Kostyrka wrote:
On Wed, 3 Feb 1999, Phillip J. Eby wrote:
The "Rapidsite/Apa" server type is the fourth most popular (by domains served) web server on the 'net, right after vanilla Apache, IIS, and Netscape Enterprise. Its current market share is about half that of NS Enterprise, with over 86,000 to Netscape's 171,000. Given that there are no real environment standards for shared hosting with other server types, RS/Apa is arguably *the* dominant shared hosting platform in existence right now, if you consider the platform to be a combination of the server, the installed software, directory structures, hardware configurations, user control panel, etc.
Actually, it's quite easy to setup with Apache if suexec was included in the compilation: It's just one directive in <VirtualHost>, so I'd consider Apache as shared as one get :)
Apache's just the server - RS/Apa goes beyond just the server to a whole host (no pun intended) of provisioning and other resources for shared hosting.
The problem is, that setting su-exec and understanding it's operation (as it's extremly security sensitive) is not trivial, so services with lower quality standards seem to ignore this configuration.
RS/Apa servers run as root, and set effective uid on every request as soon as the VirtualHost for the request is known, so suExec configuration is not an issue, and it provides much more isolation between users. But anyway, this is all a digression from the subject of Zope, except insofar as I'd like to see Zope become a part of the RS/Apa standard-issue toolset/options. :)
Kevin Dangoor wrote: || Oops, that was unclear. I meant to say that if your host gives you your || own ID, *and* executes CGI under that ID, then you have nothing else to do || except keep permissions straight. | Ahh! That's ideal! Does someone out there set it up like that? Apache provides the facility for doing this but many ISP's are either unfamiliar or uncomfortable with using suExec. Regards, Jeff Bauer Rubicon, Inc.
On Wed, 3 Feb 1999, Kevin Dangoor wrote:
| >| | >| Only if your shared hosting environment doesn't give every domain its own | >| Unix user ID and executes CGI's under that ID... :) | > | >Hmm... If the hosting company doesn't give you your own Unix uid, I don't | >think there's any way to prevent people from getting at your data... | | Oops, that was unclear. I meant to say that if your host gives you your | own ID, *and* executes CGI under that ID, then you have nothing else to do | except keep permissions straight.
Ahh! That's ideal! Does someone out there set it up like that?
That's how we have it setup at CodeIt for our customers. Your going to need to get your ISP to change a few setting though. If they're using apache they'll need to compile in suexec support. Which we had to do a little mucking around in so that we could avoid having to setup a diferent wrapper script for each client. --------------------------------------------------- - Scott Robertson Phone: 714.972.2299 - - CodeIt Computing Fax: 714.972.2399 - - http://codeit.com - ---------------------------------------------------
participants (5)
-
Andreas Kostyrka -
Jeff Bauer -
Kevin Dangoor -
Phillip J. Eby -
Scott Robertson