Re: Time for 2.4.5 ??
That is true actually, new test system - will need to look at why 2.4.4 stumbled over that, while 2.4.x did not. Many thanks for the feedback. On Fri, Jun 7, 2013 at 12:00 AM, Eric Covener wrote: > On Thu, Jun 6, 2013 at 5:56 PM, Michael Felt wrote: > > consider this a curiosity - but using the same configure command for > 2.4.4 > > and 2.4.x - with 2.4.x the filter mod_deflate.c gets included in libexec > in > > version 2.4.4, but not in 2.4.x > > > > Is this expected? the mod_deflate.so is no longer included (by > "default")? > > Maybe your current env doesn't find zlib/zlib headers? Check config.log. >
Re: svn commit: r1491221 - /httpd/httpd/trunk/modules/generators/mod_autoindex.c
On Sun, Jun 09, 2013 at 01:52:17PM -, jaillet...@apache.org wrote:
> --- httpd/httpd/trunk/modules/generators/mod_autoindex.c (original)
> +++ httpd/httpd/trunk/modules/generators/mod_autoindex.c Sun Jun 9 13:52:17
> 2013
> @@ -1840,7 +1840,7 @@ static void output_directories(struct en
> ap_rputs(" ", r);
> if (!(autoindex_opts & SUPPRESS_LAST_MOD)) {
> if (ar[x]->lm != -1) {
> -char time_str[MAX_STRING_LEN];
> +char time_str[32];
> apr_time_exp_t ts;
> apr_time_exp_lt(&ts, ar[x]->lm);
> apr_strftime(time_str, &rv, MAX_STRING_LEN,
^^
...you need to change them both.
"Forbid" directive in core?
I'd like to add an immutable Forbid directive to the core and use it in some places in the default configuration instead of "require all denied". http://people.apache.org/~covener/forbid.diff This protects from a broad
Location walk after directory walk?
Is there some historical or other reason that the location has higher
precedence that directory/files? I think the other way is much more
intuitive
/* Rerun the location walk, which overrides any map_to_storage config.
*/
if ((access_status = ap_location_walk(r))) {
return access_status;
}
(map_to_storage is what runs the directory_walk)
--
Eric Covener
cove...@gmail.com
Re: Location walk after directory walk?
Am 10.06.2013 15:37, schrieb Eric Covener: > Is there some historical or other reason that the location has higher > precedence that directory/files? I think the other way is much more > intuitive no - not from the daily use perspective Options -Indexes -ExecCGI -MultiViews +FollowSymLinks AllowOverride None Require all denied does not mean i do not need the possibility to allow a specific Locations/Aliases outside this and the same for specific exceptions inside vhosts with directives use-case: allow specific paths outside the docroot without allowing the whole directory to be accessed signature.asc Description: OpenPGP digital signature
Re: Location walk after directory walk?
> > Options -Indexes -ExecCGI -MultiViews +FollowSymLinks > AllowOverride None > Require all denied > > > does not mean i do not need the possibility to allow > a specific Locations/Aliases outside this and the > same for specific exceptions inside vhosts with > directives But none of that requires a Location that merges later, it's just more brief than a subsequent Directory/Files.
Re: "Forbid" directive in core?
On 10 Jun 2013, at 14:35, Eric Covener wrote: > I'd like to add an immutable Forbid directive to the core and use it in some > places in the default configuration instead of "require all denied". > > http://people.apache.org/~covener/forbid.diff > > This protects from a broad Directory/Files. > > I thought someone might object to the duplication w/ AAA or the presence in > the core, so opting for RTC. Just a comment: other places that do broadly similar things often have a “deny by default” philosophy. I like this approach. Obviously this isn't going to please admins with existing configurations, so is there a way to design the mechanism so it's still possible to get something more strict than we have at the moment? In terms of directives, this could look like: # For example, insiset that exemptions must be defined in the same place as the Forbid is set. Forbid ForbidExemption /srv/web /nfs/foo/bar # Require HTTPS except from IPv4 localhost # Expression evaluation doesn't need exemptions Forbid -- Tim Bannister – is...@jellybaby.net
Re: Location walk after directory walk?
Am 10.06.2013 15:58, schrieb Eric Covener: >> >> Options -Indexes -ExecCGI -MultiViews +FollowSymLinks >> AllowOverride None >> Require all denied >> >> >> does not mean i do not need the possibility to allow >> a specific Locations/Aliases outside this and the >> same for specific exceptions inside vhosts with >> directives > > But none of that requires a Location that merges later, it's just more > brief than a subsequent Directory/Files define "requires" thhere are millions of configs out there which are tested and often enough Directory/Files/Location are used in whatever combinations if someone would change the order of this merging it would be a unpredicatable change - period you can suggest such changes for Apache 2.5 or Apache 3.0 and even there only with a damned good reason - period signature.asc Description: OpenPGP digital signature
Re: "Forbid" directive in core?
On 10 Jun 2013, at 14:35, Eric Covener wrote: > I'd like to add an immutable Forbid directive to the core and use it > in some places in the default configuration instead of "require all > denied". > > http://people.apache.org/~covener/forbid.diff > > This protects from a broad supercedes Directory/Files. > > I thought someone might object to the duplication w/ AAA or the > presence in the core, so opting for RTC. Why indeed in core? The interaction of different scopes - not least Location vs filesystem paths - is a source of regular confusion. I'm not sure adding another directive with different, one-off semantics helps. Does it really override / in all circumstances? Could it create (new) gotchas with Alias, internal Rewrites, or similar mapping functions? Also the comment "Irrevocably forbids access to the enclosing scope" could easily be read as going up a level in a hierarchy (it confused me momentarily, and I had the context of the complete patch to figure out what you meant by saying "enclosing" rather than "current" or just "this"). -- Nick Kew
RE: "Forbid" directive in core?
> -Original Message- > From: Nick Kew [mailto:n...@webthing.com] > Sent: Montag, 10. Juni 2013 16:02 > To: dev@httpd.apache.org > Subject: Re: "Forbid" directive in core? > > > On 10 Jun 2013, at 14:35, Eric Covener wrote: > > > I'd like to add an immutable Forbid directive to the core and use it > > in some places in the default configuration instead of "require all > > denied". > > > > http://people.apache.org/~covener/forbid.diff > > > > This protects from a broad > supercedes Directory/Files. > > > > I thought someone might object to the duplication w/ AAA or the > > presence in the core, so opting for RTC. > > Why indeed in core? Indeed, why in core? And what is bad about "require all denied"? Regards Rüdiger
Re: "Forbid" directive in core?
On 10 Jun 2013, at 3:35 PM, Eric Covener wrote: > I'd like to add an immutable Forbid directive to the core and use it > in some places in the default configuration instead of "require all > denied". > > http://people.apache.org/~covener/forbid.diff > > This protects from a broad supercedes Directory/Files. Does Location supercede Directory/Files? My understanding is that if the Directory/Files says no, then the access is denied, regardless of what Location says. Or to state it another way, we are successful until the first directive comes along that says denied. We don't deny, and then later on change our mind and succeed again. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: "Forbid" directive in core?
On 10 Jun 2013, at 15:17, Graham Leggett wrote: > On 10 Jun 2013, at 3:35 PM, Eric Covener wrote: > >> I'd like to add an immutable Forbid directive to the core and use it in some >> places in the default configuration instead of "require all denied". >> >> http://people.apache.org/~covener/forbid.diff >> >> This protects from a broad > Directory/Files. > > Does Location supercede Directory/Files? > > My understanding is that if the Directory/Files says no, then the access is > denied, regardless of what Location says. Or to state it another way, we are > successful until the first directive comes along that says denied. We don't > deny, and then later on change our mind and succeed again. I think that “dangerous” behaviour IS how httpd behaves. Have a look at the end of http://httpd.apache.org/docs/2.4/sections.html#merging -- Tim Bannister – is...@jellybaby.net
Re: Location walk after directory walk?
On Mon, Jun 10, 2013 at 10:03 AM, Reindl Harald wrote: > > > Am 10.06.2013 15:58, schrieb Eric Covener: >>> >>> Options -Indexes -ExecCGI -MultiViews +FollowSymLinks >>> AllowOverride None >>> Require all denied >>> >>> >>> does not mean i do not need the possibility to allow >>> a specific Locations/Aliases outside this and the >>> same for specific exceptions inside vhosts with >>> directives >> >> But none of that requires a Location that merges later, it's just more >> brief than a subsequent Directory/Files > > define "requires" Necessary for the result. > thhere are millions of configs out there which are tested and > often enough Directory/Files/Location are used in whatever > combinations > if someone would change the order of this merging it would > be a unpredicatable change - period > you can suggest such changes for Apache 2.5 or Apache 3.0 > and even there only with a damned good reason - period This should be obvious, but none of it precludes discussion here - exclamation point.
Re: Location walk after directory walk?
Historically on unix it was syntactic... would you rather control access in filepath space or uri space? It seemed pretty simple to grant read access, versus the so that was an early preference still used by some admins. With case-insensitive filesystems it became a real problem. Granting access by location is still simple (request the correct case pathname for the uri, or the case-sensitive grant-ACL will fail), but denying access became tricky. Trickier still because case-flexible filesystems are also usually flexible in other, non-intuitive ways, like the handling of a trailing period on an NTFS volume. So cannot be safely used to deny file access under several OS's, including several case-insensitive unix examples such as hfs+, samba shares etc. As with most historical artifacts, history often wins the debate over 'correctness'. On Mon, Jun 10, 2013 at 9:31 AM, Eric Covener wrote: > On Mon, Jun 10, 2013 at 10:03 AM, Reindl Harald > wrote: > > > > > > Am 10.06.2013 15:58, schrieb Eric Covener: > >>> > >>> Options -Indexes -ExecCGI -MultiViews +FollowSymLinks > >>> AllowOverride None > >>> Require all denied > >>> > >>> > >>> does not mean i do not need the possibility to allow > >>> a specific Locations/Aliases outside this and the > >>> same for specific exceptions inside vhosts with > >>> directives > >> > >> But none of that requires a Location that merges later, it's just more > >> brief than a subsequent Directory/Files > > > > define "requires" > > Necessary for the result. > > > thhere are millions of configs out there which are tested and > > often enough Directory/Files/Location are used in whatever > > combinations > > > if someone would change the order of this merging it would > > be a unpredicatable change - period > > > you can suggest such changes for Apache 2.5 or Apache 3.0 > > and even there only with a damned good reason - period > > This should be obvious, but none of it precludes discussion here - > exclamation point. >
Re: Location walk after directory walk?
On 10.06.2013 15:37, Eric Covener wrote:
> Is there some historical or other reason that the location has higher
> precedence that directory/files? I think the other way is much more
> intuitive
Don't know about th real motivation, but after having learned that from
the explicit description in the docs I got very used to it. Changing it
would have major implications for existing configs.
One nice thing i saw yesterday is an explicit recipe in our docs to put
additional control on .htaccess stuff you don't want to happen by
enforcing your policy ("fixing" problematic .htaccess) with a
that merges later.
Regards,
Rainer
Re: "Forbid" directive in core?
> Why indeed in core? Started there because that's where AccessFileName lives.
Re: "Forbid" directive in core?
On Monday 10 June 2013, Tim Bannister wrote: > On 10 Jun 2013, at 15:17, Graham Leggett wrote: > > On 10 Jun 2013, at 3:35 PM, Eric Covener wrote: > >> I'd like to add an immutable Forbid directive to the core and > >> use it in some places in the default configuration instead of > >> "require all denied". > >> > >> http://people.apache.org/~covener/forbid.diff > >> > >> This protects from a broad >> supercedes Directory/Files. > > > > Does Location supercede Directory/Files? > > > > My understanding is that if the Directory/Files says no, then the > > access is denied, regardless of what Location says. Or to state > > it another way, we are successful until the first directive > > comes along that says denied. We don't deny, and then later on > > change our mind and succeed again. > > I think that “dangerous” behaviour IS how httpd behaves. Have a > look at the end of > http://httpd.apache.org/docs/2.4/sections.html#merging I think the real problem is that AuthzMerging defaults to "off". Having a default of "and" would have been a lot safer, but that cannot be changed in 2.4 anymore. And there is not even a way to make AuthzMerging default to "and" globally. Time for a "DefaultAuthzMerging XXX" or an "AuthzMerging XXX inherit" directive?
Re: "Forbid" directive in core?
On Monday 10 June 2013, Plüm, Rüdiger, Vodafone Group wrote: > > > I'd like to add an immutable Forbid directive to the core and > > > use it in some places in the default configuration instead of > > > "require all denied". > > > > > > http://people.apache.org/~covener/forbid.diff > > > > > > This protects from a broad > > supercedes Directory/Files. > > > > > > I thought someone might object to the duplication w/ AAA or the > > > presence in the core, so opting for RTC. > > > > > > > > Why indeed in core? > > Indeed, why in core? Maybe mod_authz_core would be more appropriate? > And what is bad about "require all denied"? That it is too easy to override by accident. Actually, mod_allowhandlers in trunk allows SetHandler forbidden which more or less does what Forbid does (unless one overrides the Handler later on). But that's even more confusing than a separate Forbid. I am in favor of adding something that denies and is difficult to override by accident. But maybe the combination Require all denied AuthMerging and inherit would do the trick, denoting that later sections are merged with and unless AuthMerging is set explicitly. But I guess it could still happen that this would be overriden by accident by an "AuthMerging or" later on. Another possibility would be AuthMerging immutable stating that sections merged later would be ignored. But I can't think of any sane usage except with "require all denied". So maybe the Forbid is enough?
Re: Location walk after directory walk?
On Monday 10 June 2013, Eric Covener wrote: > Is there some historical or other reason that the location has > higher precedence that directory/files? I don't know either, but I could imagine that it was just easier or more efficient to implement in this order, considering things like config walk caching, file-typed subrequests, etc.
