[Cherokee] New spawning mechanism in Cherokee 0.99.12

[Alvaro Lopez Ortega]

Hi folks!

I've just integrated (r3168) a new spawning mechanism in trunk (the
upcoming Cherokee 0.99.12 release). It's basically a much more refined
and powerful way of launching new interpreters - such as php, django,
ror, etc. It allows to do things like this:

\-+= 09736 root cherokee
|-+= 09763 www-data /usr/bin/php-cgi -b /tmp/cherokee-php.socket
| |--- 09764 www-data /usr/bin/php-cgi -b /tmp/cherokee-php.socket
| |--- 09765 www-data /usr/bin/php-cgi -b /tmp/cherokee-php.socket
| |--- 09766 www-data /usr/bin/php-cgi -b /tmp/cherokee-php.socket
| |--- 09767 www-data /usr/bin/php-cgi -b /tmp/cherokee-php.socket
| \--- 09768 www-data /usr/bin/php-cgi -b /tmp/cherokee-php.socket
\--- 09747 nobody /usr/sbin/cherokee-worker

This means that, even if cherokee-worker (the actual web server) was
running as nobody, it was able to spawn a new PHP fastcgi daemon
running as the www-data user.

If you guys have the chance, give it a try. I'd love to get feedback
from you before releasing 0.99.12. The change has been quite big, and
I wouldn't like to introduce any regression in the upcoming release.

Cheers!

--
Octality
http://www.octality.com/

_______________________________________________
Cherokee mailing list
Cher...@lists.octality.com
http://lists.octality.com/listinfo/cherokee

[Stefan de Konink]

On Sat, 25 Apr 2009, Alvaro Lopez Ortega wrote:

> This means that, even if cherokee-worker (the actual web server) was
> running as nobody, it was able to spawn a new PHP fastcgi daemon
> running as the www-data user.
>
> If you guys have the chance, give it a try. I'd love to get feedback
> from you before releasing 0.99.12. The change has been quite big, and
> I wouldn't like to introduce any regression in the upcoming release.

What did you do to prevent executable code to execute the spawn function?
Is it possible to explictly disable respawn as root at configure? (Stack
initialisation of non-zero etc.)

Stefan

[Alvaro Lopez Ortega]

On 25-abr-09, at 12:11, Stefan de Konink wrote:
> On Sat, 25 Apr 2009, Alvaro Lopez Ortega wrote:
>
>> This means that, even if cherokee-worker (the actual web server) was
>> running as nobody, it was able to spawn a new PHP fastcgi daemon
>> running as the www-data user.
>>
>> If you guys have the chance, give it a try. I'd love to get feedback
>> from you before releasing 0.99.12. The change has been quite big, and
>> I wouldn't like to introduce any regression in the upcoming release.
>
> What did you do to prevent executable code to execute the spawn
> function?

What do you mean by executable code? Cherokee-worker is the only
process that can access the spawning mechanism. No other external
process can interfere with the spawning (except of other root
processes of course).

> Is it possible to explictly disable respawn as root at configure?
> (Stack
> initialisation of non-zero etc.)

r3169 has fixed the problem - I knew I needed some feedback for a
reason. :-)

--
Octality
http://www.octality.com/

[Stefan de Konink]

On Sat, 25 Apr 2009, Alvaro Lopez Ortega wrote:

> What do you mean by executable code? Cherokee-worker is the only
> process that can access the spawning mechanism. No other external
> process can interfere with the spawning (except of other root
> processes of course).

We all know some of us are great programmers, but we all make mistakes. It
would be really nice if ever an exploit is possible, cherokee would
bitmask the UID field so it could never be zero.

> > Is it possible to explictly disable respawn as root at configure?
> > (Stack
> > initialisation of non-zero etc.)
>
> r3169 has fixed the problem - I knew I needed some feedback for a
> reason. :-)

;) I would make this number configurable in code... maybe with a hardmask.

Stefan

[Jacob Peddicord]

Great! I'm anxious to try this out, though I can't seem to get it to build now. It dies on linking: "./.libs/libcherokee-base.so: undefined reference to `shm_open'". Tried running configure again as `LDFLAGS="-lrt" ./configure`, which solves the initial shm_open problem, but then:

In function ‘open’,
    inlined from ‘do_spawn’ at main.c:359,
    inlined from ‘spawn_thread_func’ at main.c:608:
/usr/include/bits/fcntl2.h:51: error: call to ‘__open_missing_mode’ declared with attribute error: open with O_CREAT in second argument needs 3 arguments

I have glibc 2.9 if it matters. Anything I might be missing?

Thanks,
Jacob

[Alvaro Lopez Ortega]

Hello Jacob,

I have committed a little patch to fix it (r3171).
It ought to compile in Linux now.

[Jacob Peddicord]

Thanks, but it still doesn't quite build, exiting with the second error in the previous message. main.c:359 has this:
    fd = open (log_file, O_WRONLY | O_APPEND | O_CREAT);

Apparently newer versions of glibc now enforce a third parameter (mode) if O_CREAT is specified. I changed that line to:
    fd = open (log_file, O_WRONLY | O_APPEND | O_CREAT, 0600);
but I'm not sure if 0600 is exactly the right mode needed; it's just a bit of guesswork.

Anyway, _that_ error is gone with that change, but then I'm left with "undefined reference to `cherokee_logger_get_error_writer'" - which I made a shoddy attempt to work around by including logger.h into files that referenced it - needless to say that didn't work. :)

Thanks again for your work on this, I'm excited to see this all in action.
Jacob

[Alvaro Lopez Ortega]

Hello Jacob,

On 25-abr-09, at 19:50, Jacob Peddicord wrote:

> Thanks, but it still doesn't quite build, exiting with the second
> error in the previous message. main.c:359 has this:
> fd = open (log_file, O_WRONLY | O_APPEND | O_CREAT);
>
> Apparently newer versions of glibc now enforce a third parameter
> (mode) if O_CREAT is specified.

That's pretty interesting; thanks for pointing it out.

> Anyway, _that_ error is gone with that change, but then I'm left
> with "undefined reference to `cherokee_logger_get_error_writer'" -
> which I made a shoddy attempt to work around by including logger.h
> into files that referenced it - needless to say that didn't work. :)

Have you tried to clean the previous build? It happened to me as well,
and a plain "make clean all" worked it out.

[Jacob Peddicord]

On Sat, Apr 25, 2009 at 1:56 PM, Alvaro Lopez Ortega <alv...@alobbs.com> wrote:

Have you tried to clean the previous build? It happened to me as well, and a plain "make clean all" worked it out.

Just tried with a fresh checkout.

Seems it is a problem with something in cget, though I couldn't find cherokee_logger_get_error_writer anywhere in it: http://pastebin.com/f4c6ac20f

Building in cherokee/ only seems to work fine. Now to play around with this spawning. :)

[Alberto Caso]

El sáb, 25-04-2009 a las 11:55 +0200, Alvaro Lopez Ortega escribió:
> This means that, even if cherokee-worker (the actual web server) was
> running as nobody, it was able to spawn a new PHP fastcgi daemon
> running as the www-data user.

Awesome! No more suid wrappers!!

Thank you very much,

--
Alberto Caso Palomino | Adaptia
albert...@adaptia.es | http://www.adaptia.es

[Jacob Peddicord]

Been playing around with this for a couple of days, and so far no problems have arose. Looking good! :)

Jacob Peddicord
http://jacob.peddicord.net