From: Tom <tom@lemuria.org>
To: Russell Coker <russell@coker.com.au>
Cc: selinux@tycho.nsa.gov
Subject: Re: PHP and other CGI stuff
Date: Mon, 20 Jan 2003 16:25:04 +0100 [thread overview]
Message-ID: <20030120162504.D30542@lemuria.org> (raw)
In-Reply-To: <200301201505.47688.russell@coker.com.au>; from russell@coker.com.au on Mon, Jan 20, 2003 at 03:05:47PM +0100
On Mon, Jan 20, 2003 at 03:05:47PM +0100, Russell Coker wrote:
> I looked into that some time ago but discovered that PHP didn't work the same
> when invoked as an external process. When run by the php-cgi method it would
> not correctly support IMP (the only PHP software I really care about).
Hm, that's something I will have to investigate. But if it doesn't act
the same, I'd consider that a bug and report it to the PHP people.
> Due to this I was unable to determine a better solution than to have a
> seperate instance of Apache for every separate PHP domain. This consumes
> extra resources, but generally you don't have that many PHP customers...
Well, we have about 1000. So running seperate Apaches is definitely not
an option.
> second_user is designed for someone who can login via ssh, read mail with
> mutt, etc. For a different domain for web processes we need something a bit
> different. Some of the various options have been discussed here over the
> last 18 months, but nothing has been done because the Apache policy basically
> works, and is complex enough that no-one really wants to do a serious
> re-write.
Ok, then I'm starting one now. After some experimentation I think I've
found a way. But what is the performance impacts of domains and rules?
I would create 10 domains/types and about 700 rules per hosted site
(this is after macro expansion, of course).
What would the memory and performance impact of 10000 new types and 700000
rules be? If it just means another 512 MB of memory for the machine, that's
not a problem.
> I think that the entire way that Apache operates should be reviewed in light
> of the way things are currently working in SE Linux policy and the usage of
> typical systems. Many things have changed since the Apache policy was
> written, it's a bit of a dinosaur.
I posted an updated one in october, though it retains much of the old
stuff, it should be much newer. See my other posting earlier today.
--
PGP/GPG key: http://web.lemuria.org/pubkey.html
pub 1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
Key fingerprint = C731 64D1 4BCF 4C20 48A4 29B2 BF01 9FA1 2D7A 04F5
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
next prev parent reply other threads:[~2003-01-20 15:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-20 13:11 PHP and other CGI stuff Tom
2003-01-20 14:05 ` Russell Coker
2003-01-20 15:25 ` Tom [this message]
2003-01-20 16:45 ` Russell Coker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030120162504.D30542@lemuria.org \
--to=tom@lemuria.org \
--cc=russell@coker.com.au \
--cc=selinux@tycho.nsa.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.