Date: Wed, 18 Nov 1998 23:34:07 +0100 (MET) From: Per Kristian Hove <perhov@phys.ntnu.no> To: freebsd-security@FreeBSD.ORG Subject: Re: pkhttpd (Was: Would this make FreeBSD more secure?) Message-ID: <Pine.GSO.3.96.981118231651.14196E-100000@huset.math.ntnu.no> In-Reply-To: <Pine.BSF.4.05.9811181007500.19474-100000@alive.znep.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 18 Nov 1998, Marc Slemko wrote: > pkhttpd may be fine if you are only interested in something that will > often appear close enough to a web server so clients can often understand > it for a very restricted set of content. It is not fully functional, but "close enough for all practical purposes" (said the physicist:-). (Well, I agree that even that is argueable). > It doesn't read the full request headers, it doesn't output error messages > properly (outputs two sets of headers for a 404), it prints random memory > locations for unknown MIME types, it doesn't support HEAD properly > (doesn't terminate the headers with a blank line), etc. You're right. It isn't even a "lightweight server", just a small "web server wannabee" program, and it's not fully compliant with the HTTP specification. It was intended for small embedded setups, where you usually dont have evil users on the system, and certainly not use for heavy cgi stuff - most often you'll only need to show a few html pages and some very simple cgi to configure the thingee. That's why I appreciate your feedback very much. If it is improved, it might be useful other places too. > > As for its features: > > - It handles 'GET' and 'HEAD' requests and does cgi. > > No, it doesn't. It doesn't do CGI (CGI is an interface that is defined, > it isn't just running whatever program you want), and it doesn't support > even HTTP/1.0. You will face a very real problem with lost responses if > anyone ever sends headers in multiple packets, which some systems do a > lot. Again, you're right. If someone could point me to the HTTP / CGI specs, i'd be grateful. It does, though, work for all the purposes i've needed it for so far. But that's not a lot. > > - When run as root, it runs in a chroot()'ed environment. It runs > > cgi programs with the user-id of the owner of the program (and never as > > root). > > ie. on a system where someone can give away ownership of a files, this > lets them execute programs as an arbitrary UID. I don't intend to use it on e.g. HP-sUX, and never will. That 'feature' (giving away files) is so brain damaged that I do not consider it to be a problem with my server as much as a problem with the system. But you _do_ have a point, perhaps one should be able to determine upon compile whether to run cgi (as user) or not run cgi at all. Running cgi as a special user might suffice if you dont have users on your system, but it's not a pretty sight if you let your users run cgi scripts as this user. To HP-sUX's defence, it must be said that it *does* remove any setuid bits when you give away files. Not every system has done that in the past. (Hey! I have a copy of /sbin/sh on my account that i made setuid myself. I want to give it to somebody. Hm... what about root?) Any constructive ideas, perhaps? (I'll fix the HEAD so it will terminate with a blank line.) -- per kristian <perhov@phys.ntnu.no> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.3.96.981118231651.14196E-100000>