Re: "Forbid" directive in core?

[Eric Covener <co...@gmail.com>]

On Sat, Sep 28, 2013 at 12:21 PM Tim Bannister <is...@jellybaby.net> wrote:
>
> On 28 Sep 2013, at 14:19, Eric Covener <co...@gmail.com> wrote:
>
> > I've come back to this because I've struggled in another area with access_checker vs. access_checker_ex.  I really think we need basic access control outside of Require and Satisfy.
> >
> > I have a copy of the "Forbidden" directive in mod_authz_core and I am currrently allowing ON/OFF flags.
> >
> > * using a new directive means someone won't casually add "forbidden OFF" when they think they're turnong on more access control with Require
> > * we can document that "forbidden OFF" is extreme from the start.
> >
> > I am on the fence about having an argument at all.  My fear is that it will evolve into a misguided FAQ of 'try forbidden OFF if you get a 403' then we're right back to
> >
> > <Files .ht*>
> > Forbidden
> > </Files>
> >
> > ...
> >
> > <Location />
> > ...
> > Require ldap-group cn=foo
> > Forbidden OFF
> > </location>
>
> The second time in a few days, I'm going to suggest adding an optional parameter to a directive.
>
> Taking a leaf out of cascading stylesheets, how about “Forbidden On Level=Important” and perhaps “Forbidden On Level=Indelible”?
>
> (the idea being that the “Indelible” level can't be removed).
>
>
> This lets distributions ship a fairly safe default configuration but gives users enough scope to hang themselves. With this, “forbidden OFF” isn't so risky and “Forbidden Off Level=Important” can carry a health warning (and perhaps an ErrorLog warning as well).
>
>
> Too complex or worth having? What do people think? If there's appetite for it then I will have  a go at providing a patch.

Bumping a very old thread.  tl;dr people are often surprised that when
Location sections have access control directives and overlap with the
filesystem it undoes the default
<Files ".ht*">
    Require all denied
</Files>

What do currently active people think of the original basic "Forbid"
or the one with tags/levels?

Re: "Forbid" directive in core?

[Nick Kew <ni...@apache.org>]

> On 27 Apr 2020, at 16:37, Eric Covener <co...@gmail.com> wrote:
> 
> 
> Bumping a very old thread.  tl;dr people are often surprised that when
> Location sections have access control directives and overlap with the
> filesystem it undoes the default
> <Files ".ht*">
>    Require all denied
> </Files>

We always warn against mixing <Location> with filesystem.  That's just
one of many gotchas that may arise from it.

I wonder if a better solution would be to be much stricter about the division?
Ideally make it a config error (switchable to a warning so as not to break too
many old configs) to overlap them?

A first-pass implementation might be for the Location directive
to issue a warning if it matches a directory in the filesystem.

-- 
Nick Kew

Re: "Forbid" directive in core?

[Yehuda Katz <ye...@ymkatz.net>]

On Mon, Apr 27, 2020 at 11:37 AM Eric Covener <co...@gmail.com> wrote:

> On Sat, Sep 28, 2013 at 12:21 PM Tim Bannister <is...@jellybaby.net>
> wrote:
> > The second time in a few days, I'm going to suggest adding an optional
> parameter to a directive.
> >
> > Taking a leaf out of cascading stylesheets, how about “Forbidden On
> Level=Important” and perhaps “Forbidden On Level=Indelible”?
> >
> > (the idea being that the “Indelible” level can't be removed).
> >
> >
> > This lets distributions ship a fairly safe default configuration but
> gives users enough scope to hang themselves. With this, “forbidden OFF”
> isn't so risky and “Forbidden Off Level=Important” can carry a health
> warning (and perhaps an ErrorLog warning as well).
> >
> >
> > Too complex or worth having? What do people think? If there's appetite
> for it then I will have  a go at providing a patch.
>
> What do currently active people think of the original basic "Forbid"
> or the one with tags/levels?
>

Most CSS experts will tell you that "!important" is bad and if you are
using it, you didn't design your site properly. As someone who does a lot
of config support, I also think this is overly complicated.

- Y

Re: "Forbid" directive in core?

[Eric Covener <co...@gmail.com>]

On Mon, Apr 27, 2020 at 12:14 PM Yann Ylavic <yl...@gmail.com> wrote:
>
> On Mon, Apr 27, 2020 at 5:37 PM Eric Covener <co...@gmail.com> wrote:
> >
> > Bumping a very old thread.  tl;dr people are often surprised that when
> > Location sections have access control directives and overlap with the
> > filesystem it undoes the default
> > <Files ".ht*">
> >     Require all denied
> > </Files>
>
> Thanks for pointing at this, I was wondering what baptx was talking
> about on users@. TIL...
>
> What about upper sf proposal to default AuthMerging to "and"?
> Would that be too disruptive? Or at least, if this is a direction,
> could we do that in our default httpd.conf (and docs)?

AuthMerging in default conf for at least the .ht* case seems to make
sense.  Haven't tested, never occurred to me before. Maybe because it
was not analagous for 2.2 back then.

I don't think we can change the compiled-in default in 2.4.  Maybe in trunk?

Re: "Forbid" directive in core?

[Yann Ylavic <yl...@gmail.com>]

On Mon, Apr 27, 2020 at 5:37 PM Eric Covener <co...@gmail.com> wrote:
>
> Bumping a very old thread.  tl;dr people are often surprised that when
> Location sections have access control directives and overlap with the
> filesystem it undoes the default
> <Files ".ht*">
>     Require all denied
> </Files>

Thanks for pointing at this, I was wondering what baptx was talking
about on users@. TIL...

What about upper sf proposal to default AuthMerging to "and"?
Would that be too disruptive? Or at least, if this is a direction,
could we do that in our default httpd.conf (and docs)?