Mailing List Archive

All patches seem to work as advertised with exceptions noted.

B57_unmunge_alternative.txt +1
B59-include-bugs-2.txt +1
B70- " " fixes +1

P67-patch.new_dbm_group_file.txt +1


E66_cgi_no_cmd_incs.txt -1
Sounds like there are some better solutions afoot.

E63_NEW_send_file_as_is.txt +1

E68_simple_indexer.pl +1
(perl script bundle)

E71-add_description_file_parser -1 (does not apply cleanly)



72-license +1

dbmanage (perl script bundle) +1 (thanks)

Here's a summary of votes so far, please send in corrections ASAP.
There's no need to add more +1s to those already past the +3 threshold.



B57_unmunge_alternative.txt +2 rh bb

B59-include-bugs-2.txt +2.5 bb dr rh_0.5

B60-leading-slash-3.txt +3 bb rh dr

P67-patch.new_dbm_group_file.txt +2 rst bb

B64-acc-compile.txt +4 rst rh bb dr

E65-SERVER_ADMIN_CGI_env.txt +3 rh bb dd (with MAX_COMMON_VARS 13)

E66_cgi_no_cmd_incs.txt veto from bb (+2 otherwise)

E63_NEW_send_file_as_is.txt +2 rh bb

E68_simple_indexer.txt.v3 vetos from bb dr rst

E68_simple_indexer.pl +1.5 bb rh_0.5
(perl script bundle)

E71-add_description_file_parser vetos from bb dr rst

B69-misc-bugs-wall.txt +4 rh bb dr rst

E55-muitl-home +4.5 cs bb rt rst rh_0.5

B70- " " fixes +2 cs rst

72-license +2 rh bb

dmmanage (perl script bundle) +1 rh

>
> > E66_cgi_no_cmd_incs.txt -1
> > Sounds like there are some better solutions afoot.
>
>
> I'd like to know why Brian and Randy have vetoed this.

I guess I don't understand why IncludesNoEXEC does not
accomplish the same thing. Educate me.

>
> > > > E66_cgi_no_cmd_incs.txt -1
> > > > Sounds like there are some better solutions afoot.
>
> > > I'd like to know why Brian and Randy have vetoed this.
>
> > I guess I don't understand why IncludesNoEXEC does not
> > accomplish the same thing. Educate me.
>
> IncludesNoEXEC disables cgi and cmd types of include
>
> cmd are undersirable to some people, hence the need for IncludesNoEXEC,
>
> but if you already allow CGI scripts to be executed,
> you might want to just block the cmd's and let the cgi's be included.
> If you're really paranoid, you block both.

Color me dense. Why would I not allow EXEC, but allow CGI?

I'm willing to raise my vote to a 0....

:-)

> E66_cgi_no_cmd_incs.txt -1
> Sounds like there are some better solutions afoot.


I'd like to know why Brian and Randy have vetoed this.

The two objections that David raised were,

1) the name

2) the use of an "int" instead of "char" to hold allow options


-=-=

2) will be needed at some point in the future anyway. Rob T has
already proposed using it for toggling includes.

does anyone want to keep the "char" at this point ?

1) can be fixed when 0.6 is built and this would be the plan.


If this gets vetoed just because of (1), then Randy or Brian should
submit the patch again next week with a different name. I won't want
to go through the same thing next week because of another nit-pick
over a name.


end of rant.

robh

>
> > Color me dense. Why would I not allow EXEC, but allow CGI?
> >
> > I'm willing to raise my vote to a 0....
>
> CGI can be in a restricted ScriptAlias dir (and most often it is).
>
> CMD can execute anything, anywhere
>
>

Upon closer look, this seems like a reasonable option to have.
To answer the complaints regarding the variable name, could
it be changed to IncludesNOCMD?

I'll vote +1 either way, but prefer IncludesNOCMD.

> > > E66_cgi_no_cmd_incs.txt -1
> > > Sounds like there are some better solutions afoot.

> > I'd like to know why Brian and Randy have vetoed this.

> I guess I don't understand why IncludesNoEXEC does not
> accomplish the same thing. Educate me.

IncludesNoEXEC disables cgi and cmd types of include

cmd are undersirable to some people, hence the need for IncludesNoEXEC,

but if you already allow CGI scripts to be executed,
you might want to just block the cmd's and let the cgi's be included.
If you're really paranoid, you block both.

> Color me dense. Why would I not allow EXEC, but allow CGI?
>
> I'm willing to raise my vote to a 0....

CGI can be in a restricted ScriptAlias dir (and most often it is).

CMD can execute anything, anywhere

On Fri, 14 Apr 1995, Rob Hartill wrote:
> > E66_cgi_no_cmd_incs.txt -1
> > Sounds like there are some better solutions afoot.
>
> I'd like to know why Brian and Randy have vetoed this.

It has nothing to do with the name or the data structures, and everything
to do with the conviction that allowing #include to point to CGI scripts
solves this problem cleanly without introducing new security holes nor
new configuration options. I would love to be proved wrong on this.

Brian

One correction --- I haven't proposed using an extra bit for toggling
includes; you can already do that in .htaccess files. I've proposed it
for toggling the XBITHACK without having to recompile the server. (In
general, there are way too many things which are currently selectable
only as compile-time options; this not only makes it harder to put
together a decent test suite, but limits the functionality of binary
distributions).

rst

>
> On Fri, 14 Apr 1995, Rob Hartill wrote:
> > > E66_cgi_no_cmd_incs.txt -1
> > > Sounds like there are some better solutions afoot.
> >
> > I'd like to know why Brian and Randy have vetoed this.
>
> It has nothing to do with the name or the data structures, and everything
> to do with the conviction that allowing #include to point to CGI scripts
> solves this problem cleanly without introducing new security holes nor
> new configuration options. I would love to be proved wrong on this.

Allowing CGI includes is not much worse than worse than allowing the
CGI themsleves

If you don't want CMD includes - which are obviuosly insecure, then there's
no way to have CGI includes either. At least with this patch you
get the choice, and can make your own mind up.

With monitored ScriptAliased cgi (which many sites have), the
webmaster "knows" what the scripts do, he trusts them.
The "cmd" stuff cannot be monitored if users have the ability to
do includes.

I just don't understand the objection. There are no "new" security holes
which come with this, but a few holes will be plugged with it.


robh

On Fri, 14 Apr 1995, Rob Hartill wrote:
> > > I'd like to know why Brian and Randy have vetoed this.
> >
> > It has nothing to do with the name or the data structures, and everything
> > to do with the conviction that allowing #include to point to CGI scripts
> > solves this problem cleanly without introducing new security holes nor
> > new configuration options. I would love to be proved wrong on this.
>
> Allowing CGI includes is not much worse than allowing the
> CGI themsleves.

Exactly - so, was there a patch to allow
<!--#include virtual="/cgi-bin/foo" --> and I missed it? And if so, what
does IncludesNoExecYesCGI let you do that the above + IncludesNoExec
doesn't??

Sometimes I think some of these issues need to be resolved in a forum
other than email....

> With monitored ScriptAliased cgi (which many sites have), the
> webmaster "knows" what the scripts do, he trusts them.
> The "cmd" stuff cannot be monitored if users have the ability to
> do includes.

Totally understood.

> I just don't understand the objection. There are no "new" security holes
> which come with this, but a few holes will be plugged with it.

I think we're crossing wires somewhere....

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/

> Let me explain what I see as the disagreement.

thanks. I'm building 0.6 now without the CGI/CMD stuff. I'll leave it
to others to provide a "better" patch at a later date.

0.6.. coming soon to an apache.org near you.

robh

> 0.6.. coming soon to an apache.org near you.

Damn, it was ready a few minutes ago, but I couldn't find "APB"
in the source so I started again... hmmm. B70 removes APB. Doh !

> Damn, it was ready a few minutes ago, but I couldn't find "APB"
> in the source so I started again... hmmm. B70 removes APB. Doh !

Slight problem

the new Makefile refers to APB. Should I just rename the CFLAGS to
reflect the comments ? It looks like I should


-=-=-=-

# If you want multihomed support via virtual hosts or bind address
# restriction, define -DMULTI_ADDRESS_BIND and -DVIRTUAL_HOST.
#

#CFLAGS= -O2
CFLAGS= -g -DAPB_BIND_ADDRESS -DAPB_VIRTUAL_HOST

>E55-muitl-home +4.5 cs bb rt rst rh_0.5
I voted -0.5 on this.
>72-license +2 rh bb
I voted +1 on this.

David.

Brian wrote:
> > Allowing CGI includes is not much worse than allowing the
> > CGI themsleves.
>
> Exactly - so, was there a patch to allow
> <!--#include virtual="/cgi-bin/foo" --> and I missed it? And if so, what
> does IncludesNoExecYesCGI let you do that the above + IncludesNoExec
> doesn't??
>
> ...
> > With monitored ScriptAliased cgi (which many sites have), the
> > webmaster "knows" what the scripts do, he trusts them.
> > The "cmd" stuff cannot be monitored if users have the ability to
> > do includes.
>
> Totally understood.
>
> > I just don't understand the objection. There are no "new" security holes
> > which come with this, but a few holes will be plugged with it.
>
> I think we're crossing wires somewhere....
>
> Brian

Let me explain what I see as the disagreement.

Option value
Includes IncludesNoExec IncludesNoCMD*
Current status:
#include virtual="/cgi-bin/script" No No -
#exec cmd="./hack.pl" Yes No -
Brians preference
#include virtual="/cgi-bin/script" Yes Yes -
#exec cmd="./hack.pl" Yes No -
Rob's patch
#include virtual="/cgi-bin/script" Yes No Yes
#exec cmd="./hack.pl" Yes No No

*Actually IncludesYesCGInoCMD

I too would prefer the behaviour of options=Includes and IncludesNoExec
to change to allow #include of CGI scripts that would be executable by
the client anyway.

I haven't checked that the patch does _not_ allow
#include=file="/my/cgi-script", i.e. only allows execution of scripts that
have a URL.

David.