We are using the SSL. No problems so far.
The idea seems familiar from mpm-itk. But i'm afraid that's all I can
comment.
If it could be implemented with peruser, then it might be undone just
because there is not enough free time and also the fact that "this part
of code works" at the moment :)
Finn Thain wrote:
On Sun, 27 Jul 2008, I wrote:
Hi all,
I've just been reading up on the peruser mpm. I like the idea because it
solves a real problem I'm having. I have a couple of questions, though.
As I understand it, apache listens on the network while running as root.
Is this not a security risk? Secondly, peruser MPM is not part of
upstream apache. What has prevented it from being merged?
I've a third question-- is anyone using SSL with peruser? The FAQ isn't
very encouraging on that topic.
Has anyone looked at using filesystem capabilities to avoid the root
daemon issue? It seems Linux 2.6.26 got a useable capabilities model (see
http://lwn.net/Articles/280279/
I think it would be possible to arrange to setuid/gid to an unprivileged
user (e.g. httpd/httpd), as with standard apache.
The plan would be to drop all root privilege except for the CAP_SETUID,
CAP_SETGID and CAP_SYS_CHROOT capabilities, which would be inherited by
child processes. The child processes would permanently drop those
capabilities as soon as peruser_setup_child() is finished with them.
CAP_SETUID still leaves the network daemon with more privilege than it
needs, so then we just need a kernel patch that refuses to honour the
CAP_SETUID/GID unless the requested setuid/gid is greater than the maximum
system account uid/gid (which would probably have to be set with sysctl).
Does this make any sense?
Regards,
Finn Thain
_______________________________________________
Peruser mailing list
[email protected]
http://www.telana.com/mailman/listinfo/peruser
--
Janno Sannik
DataCode OÜ
_______________________________________________
Peruser mailing list
[email protected]
http://www.telana.com/mailman/listinfo/peruser
