Hello.
As I am really annoyed by the confusing configuration-"possibilities" of apache, and as lighttpd doesnt support what I want to do in its stable release, I want to run hunchentoot in the first place. However, there are two problems:
At first, I cannot run a usermode-process listening on port 80. I am using sbcl, so I could use sb-posix:setuid after starting hunchentoot and gaining port 80, removing root-privileges. Or I could forward port 80 to port 8000 via firewall policies.
I would prefer the first possibility. The question is, if there is anything millitating against starting hunchentoot as root and then using setuid. I.e. any security issues that could result from it, anything that maybe wont work, etc.
Another thing is the question if there is some proxy- or passthrough-module for hunchentoot. I still have some php-pages I want to host (even though I will use lighttpd rather than apache for this), and would therefore need to pass them to another server in the background.
Regards, Christoph Senjak
On Fri, Oct 16, 2009 at 8:10 PM, Christoph Senjak christoph.senjak@googlemail.com wrote:
As I am really annoyed by the confusing configuration-"possibilities" of apache, and as lighttpd doesnt support what I want to do in its stable release, I want to run hunchentoot in the first place. However, there are two problems:
At first, I cannot run a usermode-process listening on port 80. I am using sbcl, so I could use sb-posix:setuid after starting hunchentoot and gaining port 80, removing root-privileges. Or I could forward port 80 to port 8000 via firewall policies.
I would prefer the first possibility. The question is, if there is anything millitating against starting hunchentoot as root and then using setuid. I.e. any security issues that could result from it, anything that maybe wont work, etc.
I've done that a couple of times, but mainly for testing purposes. I'm not aware of any problems, but maybe others are.
Another thing is the question if there is some proxy- or passthrough-module for hunchentoot. I still have some php-pages I want to host (even though I will use lighttpd rather than apache for this), and would therefore need to pass them to another server in the background.
I don't know of any such module. It'd be nice to have, though... :)
I am using sbcl, so I could use sb-posix:setuid after starting hunchentoot and gaining port 80, removing root-privileges.
(sb-posix::define-call "initgroups" int minusp (user c-string) (group sb-posix::gid-t)) (sb-posix::define-call "prctl" int minusp (option int) (arg int)) (sb-posix:prctl +PR_SET_KEEPCAPS+ 1)
(sb-posix:setresgid gid gid gid) (sb-posix:initgroups name gid) (sb-posix:setresuid uid uid uid))
(load-shared-object (find-if #'probe-file '("/lib/libcap.so.2" "/lib/libcap.so")))
(sb-posix::define-call "cap_from_text" (* char) null-alien (text c-string)) (sb-posix::define-call "cap_set_proc" int minusp (cap_p (* char))) (sb-posix::define-call "cap_free" int minusp (cap_p (* char)))
(let ((cap_p (sb-posix:cap-from-text "CAP_NET_BIND_SERVICE=ep"))) (sb-posix:cap-set-proc cap_p) (sb-posix:cap-free cap_p))
(hunchentoot:start (make-instance 'hunchentoot:acceptor :port 80))
I use this code for run http://lisper.ru/ Required libcap2. Tested on Debian and Gentoo.
Full script: http://github.com/archimag/rulisp/blob/devel/rulisp-daemon.lisp http://lisper.ru/apps/format/15 Andrey
2009/10/16 Christoph Senjak christoph.senjak@googlemail.com
Hello.
As I am really annoyed by the confusing configuration-"possibilities" of apache, and as lighttpd doesnt support what I want to do in its stable release, I want to run hunchentoot in the first place. However, there are two problems:
At first, I cannot run a usermode-process listening on port 80. I am using sbcl, so I could use sb-posix:setuid after starting hunchentoot and gaining port 80, removing root-privileges. Or I could forward port 80 to port 8000 via firewall policies.
I would prefer the first possibility. The question is, if there is anything millitating against starting hunchentoot as root and then using setuid. I.e. any security issues that could result from it, anything that maybe wont work, etc.
Another thing is the question if there is some proxy- or passthrough-module for hunchentoot. I still have some php-pages I want to host (even though I will use lighttpd rather than apache for this), and would therefore need to pass them to another server in the background.
Regards, Christoph Senjak
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Christoph Senjak wrote:
Another thing is the question if there is some proxy- or passthrough-module for hunchentoot. I still have some php-pages I want to host (even though I will use lighttpd rather than apache for this), and would therefore need to pass them to another server in the background.
That shouldn't be hard to code. There is also the possibility to use CGI with Hunchentoot and PHP for that, see:
http://cyrusharmon.org/projects?project=hunchentoot-cgi
Best,
Leslie
2009/10/17 Leslie P. Polzer sky@viridian-project.de:
Christoph Senjak wrote:
Another thing is the question if there is some proxy- or passthrough-module for hunchentoot. I still have some php-pages I want to host (even though I will use lighttpd rather than apache for this), and would therefore need to pass them to another server in the background.
That shouldn't be hard to code. There is also the possibility to use CGI with Hunchentoot and PHP for that, see:
http://cyrusharmon.org/projects?project=hunchentoot-cgi
Best,
Ah nice. Actually, yesterday I was reading the CGI-Specification to code exactly this. Thank you. I will try to use php-cgi. This is the default fastcgi-interpreter, but it also has a cgi-interface.
Regards Christoph
Hello again.
That shouldn't be hard to code. There is also the possibility to use CGI with Hunchentoot and PHP for that, see:
http://cyrusharmon.org/projects?project=hunchentoot-cgi
Best,
Ah nice. Actually, yesterday I was reading the CGI-Specification to code exactly this. Thank you. I will try to use php-cgi. This is the default fastcgi-interpreter, but it also has a cgi-interface.
Well, I had to add SCRIPT_FILENAME to the environment-variables that are passed to the CGI-Scripts to be able to run php-scripts (it took me a day to find this documented - google loves to list php-tutorials with no helpful content ...). Now I can run them - sort of. But seems like the session-management somehow doesnt work. I also added a line
("HTTP_COOKIE" . ,(let ((r "")) (dolist (cookie (hunchentoot:cookies-in*)) (setf r (concatenate 'string (car cookie) "=" (cdr cookie) ";" r))) r))
which adds the environmental-variable HTTP_COOKIE and should be correct (I couldnt find out whether the cookies should be separated via a semicolon or something else, but seems like semicolon is right, nor could I find out whether to encode these cookies somehow before putting them i this variable, but seems like none of the cookies I saw has any special characters). There seems to be a cookie sent to the php-script. When adding a (format t r), I see a string of the form sid=<random-sid>. So the php-engine /should/ know about the cookies. Still, it doesnt work. Could it be that hunchentoot doesnt list some cookies in (hunchentoot:cookies-in*), or removes outgoing cookies?
Or any Ideas what else I have to set?
Regards, Christoph
Hi Christoph,
- google loves to list php-tutorials with no helpful content ...).
That's probably because there are a lot of beginner tutorials for PHP, and hardly any serious stuff. ;)
Now I can run them - sort of. But seems like the session-management somehow doesnt work. I also added a line
("HTTP_COOKIE" . ,(let ((r "")) (dolist (cookie (hunchentoot:cookies-in*)) (setf r (concatenate 'string (car cookie) "=" (cdr cookie) ";" r))) r))
Side note: you probably want to use FORMAT or REDUCE here.
which adds the environmental-variable HTTP_COOKIE and should be correct (I couldnt find out whether the cookies should be separated via a semicolon or something else, but seems like semicolon is right, nor could I find out whether to encode these cookies somehow before putting them i this variable, but seems like none of the cookies I saw has any special characters). There seems to be a cookie sent to the php-script. When adding a (format t r), I see a string of the form sid=<random-sid>. So the php-engine /should/ know about the cookies.
IIRC sid is set by Hunchentoot and PHP's session cookie is named PHPSESSID by default.
Still, it doesnt work. Could it be that hunchentoot doesnt list some cookies in (hunchentoot:cookies-in*), or removes outgoing cookies?
Unlikely.
Or any Ideas what else I have to set?
You need to do some comparative debugging with Apache/PHP-CGI and Hunchentoot/PHP-CGI, since Apache is supposed to do the right thing.
Have a simple PHP script at the other end that lists the contents of HTTP_COOKIE.
Leslie
On Sun, Oct 18, 2009 at 5:03 AM, Christoph Senjak christoph.senjak@googlemail.com wrote:
Well, I had to add SCRIPT_FILENAME to the environment-variables that are passed to the CGI-Scripts to be able to run php-scripts (it took me a day to find this documented - google loves to list php-tutorials with no helpful content ...). Now I can run them - sort of. But seems like the session-management somehow doesnt work. I also added a line
("HTTP_COOKIE" . ,(let ((r "")) (dolist (cookie (hunchentoot:cookies-in*)) (setf r (concatenate 'string (car cookie) "=" (cdr cookie) ";" r))) r))
which adds the environmental-variable HTTP_COOKIE and should be correct (I couldnt find out whether the cookies should be separated via a semicolon or something else, but seems like semicolon is right, nor could I find out whether to encode these cookies somehow before putting them i this variable, but seems like none of the cookies I saw has any special characters).
There are RFCs where this is documented. You should either send multiple cookie headers for multiple cookies or separate them with commas. Note that some servers violate the RFCs, though. See current discussion on Drakma mailing list.
And, yes, cookie should be encoded as well. Look at Hunchentoot's source code.
There seems to be a cookie sent to the php-script. When adding a (format t r), I see a string of the form sid=<random-sid>. So the php-engine /should/ know about the cookies. Still, it doesnt work. Could it be that hunchentoot doesnt list some cookies in (hunchentoot:cookies-in*), or removes outgoing cookies?
Or any Ideas what else I have to set?
Can you look (from the PHP side) at ALL the headers recevied. That should be the first step in debugging.