You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Dean Gaudet <dg...@arctic.org> on 1997/10/12 01:32:41 UTC
I'll be scarce.
I no longer have time to main STATUS reports, so that's it for 1.3b1 until
someone else steps up to do the work. Someone else will have to roll a
new tarball with the NT fixes, and do the announcement and all that stuff.
I'll be a lot more scarce from here on out, I was trying to stick around
until after b1 was out so that I'd be able to work on bug reports.
But here it is October 11th, and b1 is well over a month late, and few
of the core members seem to have enough time to vote on anything.
I personally think it's unfortunate that we're letting NT slow down the
progress of the unix port. I don't understand why we have to release
both on the same schedule.
1.3b1 is quite stable on unix, at least what I've been using is quite
stable. I'm sure there are bugs. But we're only making the beta cycle
painfully longer by tying unix releases to the same cycle as NT releases.
Dean
Re: I'll be scarce.
Posted by Marc Slemko <ma...@worldgate.com>.
I'm not sure that is practical. The problem is that then people have to
do a wait for things to calm down, make sure the tree is ready for a beta
or whatever release, do the release, get going again for _both_ NT and
Unix releases. That means you end up with twice as much hassle.
On Mon, 13 Oct 1997, Ben Laurie wrote:
> Marc Slemko wrote:
> >
> > On Mon, 13 Oct 1997, Ben Laurie wrote:
> >
> > >
> > > I agree. I can't see a problem with releasing Unix and NT
> > > asynchronously. It's unlikely to be possible to be exactly synchronous,
> > > anyway.
> >
> > I'm not sure I understand the idea.
> >
> > Are you saying we release a 5.2b40 but only for NT, then the next release
> > is 5.2b41 but only for Unix, then b42 and b43 are only NT, etc.?
>
> Yes. Of course, if we happen to do both at the same time, that's great.
>
> Cheers,
>
> Ben.
>
> --
> Ben Laurie |Phone: +44 (181) 735 0686|Apache Group member
> Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org
> and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
> A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
> London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
>
Re: I'll be scarce.
Posted by Ben Laurie <be...@algroup.co.uk>.
Marc Slemko wrote:
>
> On Mon, 13 Oct 1997, Ben Laurie wrote:
>
> >
> > I agree. I can't see a problem with releasing Unix and NT
> > asynchronously. It's unlikely to be possible to be exactly synchronous,
> > anyway.
>
> I'm not sure I understand the idea.
>
> Are you saying we release a 5.2b40 but only for NT, then the next release
> is 5.2b41 but only for Unix, then b42 and b43 are only NT, etc.?
Yes. Of course, if we happen to do both at the same time, that's great.
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686|Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Re: I'll be scarce.
Posted by Marc Slemko <ma...@worldgate.com>.
On Mon, 13 Oct 1997, Ben Laurie wrote:
>
> I agree. I can't see a problem with releasing Unix and NT
> asynchronously. It's unlikely to be possible to be exactly synchronous,
> anyway.
I'm not sure I understand the idea.
Are you saying we release a 5.2b40 but only for NT, then the next release
is 5.2b41 but only for Unix, then b42 and b43 are only NT, etc.?
Re: I'll be scarce.
Posted by Ben Laurie <be...@algroup.co.uk>.
Dean Gaudet wrote:
>
> I no longer have time to main STATUS reports, so that's it for 1.3b1 until
> someone else steps up to do the work. Someone else will have to roll a
> new tarball with the NT fixes, and do the announcement and all that stuff.
>
> I'll be a lot more scarce from here on out, I was trying to stick around
> until after b1 was out so that I'd be able to work on bug reports.
> But here it is October 11th, and b1 is well over a month late, and few
> of the core members seem to have enough time to vote on anything.
>
> I personally think it's unfortunate that we're letting NT slow down the
> progress of the unix port. I don't understand why we have to release
> both on the same schedule.
>
> 1.3b1 is quite stable on unix, at least what I've been using is quite
> stable. I'm sure there are bugs. But we're only making the beta cycle
> painfully longer by tying unix releases to the same cycle as NT releases.
I agree. I can't see a problem with releasing Unix and NT
asynchronously. It's unlikely to be possible to be exactly synchronous,
anyway.
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686|Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Re: I'll be scarce.
Posted by Brian Behlendorf <br...@organic.com>.
At 10:26 AM 10/12/97 -0400, Jim Jagielski wrote:
>I'll step up...
>
>I can hear the groaning already :) :) :)
>
>Unless there are people who don't want me to take over
>as RM, I'll start STATUS on Monday.
That's cool with me. I'm willing to step up too when you're ready to pass
it on.
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
"it's a big world, with lots of records to play." - sig brian@organic.com
Received: (qmail 25171 invoked by uid 6000); 12 Oct 1997 23:28:17 -0000
Received: (qmail 25152 invoked from network); 12 Oct 1997 23:28:16 -0000
Received: from twinlark.arctic.org (204.62.130.91)
by taz.hyperreal.org with SMTP; 12 Oct 1997 23:28:16 -0000
Received: (qmail 7386 invoked by uid 500); 12 Oct 1997 23:28:44 -0000
Date: Sun, 12 Oct 1997 16:28:44 -0700 (PDT)
From: Dean Gaudet <dg...@arctic.org>
To: new-httpd@apache.org
Subject: new security model (was Re: [CONTRIB] listenwrap)
In-Reply-To: <Pi...@twinlark.arctic.org>
Message-ID: <Pi...@twinlark.arctic.org>
Organization: Transmeta Corp.
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org
I don't know if anyone else realised it, but this is the basis of a much
more secure apache. i.e. an apache that needs root for almost nothing.
Tell me if I've forgotten anything here:
user:group --
httpd:httpd
The user:group under which the httpd daemons run. All content files
must be accessible to at least group httpd in order to be served.
In fact recommend that all content files have world read.
Should only be able to write in $SERVERROOT/pids/httpd
(a directory).
No other user should be in group httpd.
httplog:httplog
The user:group under which the httplog process runs. Should have
write access to $SERVERROOT/logs and $SERVERROOT/pids/httplog
(a directory).
How to build a $SERVERROOT:
mkdir $SERVERROOT
cd $SERVERROOT
chown root.root .
mkdir htdocs bin bin/protectlog logs pids pids/httpd pids/httplog conf
chown root.root bin pids conf
chmod 755 bin pids conf
chown root.httpd bin/protectlog
chmod 750 bin/protectlog
chown httplog.httplog logs
chmod 775 logs
chown httpd.httpd pids/httpd
chown httplog.httplog pids/httplog
chmod 755 pids/httpd pids/httplog
chown x.x htdocs # x.x depends on how your site works, but regardless
# it should be world readable
bin/ contains:
httpd mode 555, owned by root.root
listenwrap mode 555, owned by root.root
protectlog/httplog mode 6555, owned by httplog.httplog
(i.e. setuid/gid httplog)
suexec -- setuid root
apachectl mode 555, owned by root.root
Extend listenwrap suitably so that it can parse a conf/ file containing
the Listen directives. apachectl spawns listenwrap with the appropriate
command line arguments for httpd.
listenwrap opens the listen sockets and then does a setuid/gid to
httpd:httpd, and execs httpd.
httpd then spawns bin/protectlog/httplog (which you'll note can only be
started by root or by processes in group httpd, which should only be
the httpd processes) to write all log files. The log writing occurs as
user:group httplog:httplog. It can respawn this as necessary (reliable
piped logs).
httpd writes its pid in pids/httpd/httpd.pid, and httplog writes its pid
in pids/httplog/httplog.pid.
suexec protects the httpd user from doing things it shouldn't, like running
arbitrary CGIs.
Known problems: any httpd:httpd task can spawn httplog ... when what we really
want is only the parent to be able to spawn httplog.
Alternate solution: Move more of the priveleged things into a supervisor
(call it apsupervisor) above the parent. It would:
- open the Listen sockets
- open log pipes, spawn the logger (it would do this using the reliable
technique)
- fork(), drop priveleges, exec httpd passing it the appropriate arguments
- write the logger pids and httpd pids itself
- monitor the logger
In this scenario the logger only needs write permission to
$SERVERROOT/logs, and httpd needs absolutely no write permission anywhere
(except to create the lock file).
Rotating logs is achieved by sending a HUP to the logger. Re-reading the
config is achieved by sending a HUP/USR1 to httpd.
Note that in this scenario only one access_log and one error_log is used,
so that config updates to add more vhosts do not require any logging
changes. Furthermore it only works well when vhost additions also don't
require more Listen statements. This is pretty reasonable because you
shouldn't have to run multiple httpds in this situation since you won't
run out of file descriptors.
The advantage of doing this is that apsupervisor could be made into a very
small program, which is far easier to verify the correctness of. And
httpd itself has absolutely no privelege anywhere in the system.
I kinda like this.
Dean