You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Rich Bowen <rb...@rcbowen.com> on 2003/05/09 19:36:29 UTC
403's not getting logged?
I'm experiencing a should-not-happen condition in apache 1.3.27, and
wondered if anyone else could verify for me. In the case of a 403
error caused by incorrect directory permissions, there is no error
log entry. If the file is unreadable, the 403 goes in the error log.
But if the directory has bogus permissions, there's no entry.
This is on 1.3.27 I've tested this on 2 servers so far, and it seems
consistent.
Specifically:
Directory is 755, file is 644, everything happy
Directory is 755, file is 600, 403 entry in access log, and a
"permission denied" error in error log.
Directory is 700, file is 644, 403 entry in access log, no entry made in
error log.
--
Rich Bowen - rbowen@rcbowen.com
... and another brother out of his mind, and another brother out at New
York (not the same, though it might appear so)
Somebody's Luggage (Charles Dickens)
Re: 403's not getting logged?
Posted by Rich Bowen <rb...@rcbowen.com>.
On Fri, 9 May 2003, Joshua Slive wrote:
>
> On Fri, 9 May 2003, Jeff Trawick wrote:
> > hurray for truss!
>
> Good quick sluthing.
>
> > > If a directory has insufficient perms (700), apache will report in
> > the error_log that "stat() returned u\
> > nexpected error[13]" for _each_ possible index file in
> > srm.con:DirectoryIndex. Errno 13, according to /us\
> > r/include/sys/errno.h, is EACCES "Permissio
> > n denied". This tends to fill up the error_log unnecessarily, and more
> > important error messages get lost \
> > in the noise. I would imagine the code should check to see if the
> > errno=EACCES, and just return FORBIDDEN\
> > , without logging an error.
>
> Having one error for each item in the DirectoryIndex (ie, one for
> index.html, index.htm, and index.php) seems like a small penalty for
> deobfiscating this error. I hope, however, that the OS returns a useful
> error like (from the freebsd stat() manpage) "Search permission is denied
> for a component of the path prefix."
>
> Anyway, +1 on concept for reversing that change, but I don't have a 1.3
> install to test.
Yes. I am also +1 on this, and have numerous 1.3 installations on which
I can test it.
--
Rich Bowen
Apache - mod_perl - Perl - CGI
http://www.ApacheAdmin.com/
Re: 403's not getting logged?
Posted by Joshua Slive <jo...@slive.ca>.
On Fri, 9 May 2003, Jeff Trawick wrote:
> hurray for truss!
Good quick sluthing.
> > If a directory has insufficient perms (700), apache will report in
> the error_log that "stat() returned u\
> nexpected error[13]" for _each_ possible index file in
> srm.con:DirectoryIndex. Errno 13, according to /us\
> r/include/sys/errno.h, is EACCES "Permissio
> n denied". This tends to fill up the error_log unnecessarily, and more
> important error messages get lost \
> in the noise. I would imagine the code should check to see if the
> errno=EACCES, and just return FORBIDDEN\
> , without logging an error.
Having one error for each item in the DirectoryIndex (ie, one for
index.html, index.htm, and index.php) seems like a small penalty for
deobfiscating this error. I hope, however, that the OS returns a useful
error like (from the freebsd stat() manpage) "Search permission is denied
for a component of the path prefix."
Anyway, +1 on concept for reversing that change, but I don't have a 1.3
install to test.
Joshua.
Re: 403's not getting logged?
Posted by Jeff Trawick <tr...@attglobal.net>.
Joshua Slive wrote:
> OK. Here is a tested patch, but I'll wait for a couple explicit +1s
> before committing.
+1 from me (tested)
> I'm not sure if perhaps the message should say "... because search
> permissions (chmod +x) are missing ..." to help newbies.
the message is plenty long already
Re: 403's not getting logged?
Posted by Rich Bowen <rb...@rcbowen.com>.
On Fri, 9 May 2003, Joshua Slive wrote:
> OK. Here is a tested patch, but I'll wait for a couple explicit +1s
> before committing.
+1
> I'm not sure if perhaps the message should say "... because search
> permissions (chmod +x) are missing ..." to help newbies.
That would not only help the newbies, it would help the "tech support"
people who are faced with the beligerent newbies who insist that the
directory does not need to be +x because nothing is being executed. Yes,
I know, they are being silly, but having supporting evidence in the
error message would save a few pointless arguments on IRC, if nothing
else.
I like verbose error messages, particularly those that nudge the user
towards the solution.
> Index: http_request.c
> ===================================================================
> RCS file: /home/cvs/apache-1.3/src/main/http_request.c,v
> retrieving revision 1.168
> diff -u -d -b -u -r1.168 http_request.c
> --- http_request.c 3 Feb 2003 17:13:23 -0000 1.168
> +++ http_request.c 9 May 2003 20:27:32 -0000
> @@ -288,7 +288,12 @@
> }
> else {
> #if defined(EACCES)
> - if (errno != EACCES)
> + if (errno == EACCES)
> + ap_log_rerror(APLOG_MARK, APLOG_ERR, r,
> + "access to %s failed because search "
> + "permissions are missing on a component "
> + "of the path", r->uri);
> + else
> #endif
> ap_log_rerror(APLOG_MARK, APLOG_ERR, r,
> "access to %s failed", r->uri);
>
>
--
Rich Bowen
Apache - mod_perl - Perl - CGI
http://www.ApacheAdmin.com/
Re: 403's not getting logged?
Posted by Joshua Slive <jo...@slive.ca>.
On Fri, 9 May 2003, Rich Bowen wrote:
> > > Now, it might be nice if it was more explicit, but at least this error
> > > message give a clue where to look.
> >
> > As long as we are taking all this trouble, we might as well special case
> > the EACCES error and return something more specific.
>
> +1
OK. Here is a tested patch, but I'll wait for a couple explicit +1s
before committing.
I'm not sure if perhaps the message should say "... because search
permissions (chmod +x) are missing ..." to help newbies.
Index: http_request.c
===================================================================
RCS file: /home/cvs/apache-1.3/src/main/http_request.c,v
retrieving revision 1.168
diff -u -d -b -u -r1.168 http_request.c
--- http_request.c 3 Feb 2003 17:13:23 -0000 1.168
+++ http_request.c 9 May 2003 20:27:32 -0000
@@ -288,7 +288,12 @@
}
else {
#if defined(EACCES)
- if (errno != EACCES)
+ if (errno == EACCES)
+ ap_log_rerror(APLOG_MARK, APLOG_ERR, r,
+ "access to %s failed because search "
+ "permissions are missing on a component "
+ "of the path", r->uri);
+ else
#endif
ap_log_rerror(APLOG_MARK, APLOG_ERR, r,
"access to %s failed", r->uri);
Re: 403's not getting logged?
Posted by Rich Bowen <rb...@rcbowen.com>.
On Fri, 9 May 2003, Joshua Slive wrote:
>
> On Fri, 9 May 2003, Rich Bowen wrote:
>
> > On Fri, 9 May 2003, Jeff Trawick wrote:
> >
> > > Anybody want to see if backing out the change still results in multiple
> > > error log entries for a directory listing?
> >
> > With LogLevel set at debug, I'm just getting:
> >
> > [Fri May 9 15:33:11 2003] [error] [client 127.0.0.1] (13)Permission
> > denied: access to /index.html failed
> >
> > No multiple log entries.
>
> What does your DirectoryIndex directive look like? Try something like
> DirectoryIndex a b c d e
Ah, yes, I get:
[Fri May 9 16:10:43 2003] [error] [client 127.0.0.1] (13)Permission
denied: access to /index.html failed
[Fri May 9 16:10:43 2003] [error] [client 127.0.0.1] (13)Permission
denied: access to /a failed
[Fri May 9 16:10:43 2003] [error] [client 127.0.0.1] (13)Permission
denied: access to /b failed
[Fri May 9 16:10:43 2003] [error] [client 127.0.0.1] (13)Permission
denied: access to /d failed
[Fri May 9 16:10:43 2003] [error] [client 127.0.0.1] (13)Permission
denied: access to /c failed
> > Now, it might be nice if it was more explicit, but at least this error
> > message give a clue where to look.
>
> As long as we are taking all this trouble, we might as well special case
> the EACCES error and return something more specific.
+1
--
Rich Bowen - rbowen@rcbowen.com
http://kenya.rcbowen.com/
Re: 403's not getting logged?
Posted by Joshua Slive <jo...@slive.ca>.
On Fri, 9 May 2003, Rich Bowen wrote:
> On Fri, 9 May 2003, Jeff Trawick wrote:
>
> > Anybody want to see if backing out the change still results in multiple
> > error log entries for a directory listing?
>
> With LogLevel set at debug, I'm just getting:
>
> [Fri May 9 15:33:11 2003] [error] [client 127.0.0.1] (13)Permission
> denied: access to /index.html failed
>
> No multiple log entries.
What does your DirectoryIndex directive look like? Try something like
DirectoryIndex a b c d e
> Now, it might be nice if it was more explicit, but at least this error
> message give a clue where to look.
As long as we are taking all this trouble, we might as well special case
the EACCES error and return something more specific.
Joshua.
Re: 403's not getting logged?
Posted by Rich Bowen <rb...@rcbowen.com>.
On Fri, 9 May 2003, Jeff Trawick wrote:
> Anybody want to see if backing out the change still results in multiple
> error log entries for a directory listing?
With LogLevel set at debug, I'm just getting:
[Fri May 9 15:33:11 2003] [error] [client 127.0.0.1] (13)Permission
denied: access to /index.html failed
No multiple log entries.
Now, it might be nice if it was more explicit, but at least this error
message give a clue where to look.
--
Rich Bowen - rbowen@rcbowen.com
Author - Apache Administrator's Guide
http://www.ApacheAdmin.com/
Re: 403's not getting logged?
Posted by Jeff Trawick <tr...@attglobal.net>.
Joshua Slive wrote:
> On Fri, 9 May 2003, Rich Bowen wrote:
>
>
>>I'm experiencing a should-not-happen condition in apache 1.3.27, and
>>wondered if anyone else could verify for me. In the case of a 403
>>error caused by incorrect directory permissions, there is no error
>>log entry. If the file is unreadable, the 403 goes in the error log.
>>But if the directory has bogus permissions, there's no entry.
>>This is on 1.3.27 I've tested this on 2 servers so far, and it seems
>>consistent.
>
>
> Yes, this is a very longstanding and very irritating omission. I don't
> think I would be exagerating if I said this was the source of hundreds of
> confused queries to the users mailing list and newsgroup.
>
> I browsed through the default handler a while back trying to figure out
> where this error was getting dropped, but I ran out of time and never got
> back to it. Someone who knows the code better could probably find it
> faster.
hurray for truss!
/1: -> directory_walk(0x15a170, 0x0, 0x0, 0x0)
/1: -> ap_os_is_path_absolute(0x15a938, 0x0, 0x0, 0x0)
/1: <- ap_os_is_path_absolute() = 1
/1: -> get_path_info(0x15a170, 0x0, 0x0, 0x0)
stat("/export/home/trawick/apache13inst/htdocs/test/gobble.html",
0x0015A238) Err#13 EACCES
/1: <- get_path_info() = 403
/1: <- directory_walk() = 403
/1: -> ap_die(0x193, 0x15a170, 0x0, 0x0)
A check was added for eaccess with r1.40 of src/main/http_request.c:
The below patch makes the error message a bit more standard and doesn't
print it if the reason for stat failing was EACCES. Should go in before
the beta goes out.
Reviewed by: Randy Terbush
Submitted by: Marc Slemko
Here is how to back it out:
diff -u -r1.168 http_request.c
--- src/main/http_request.c 3 Feb 2003 17:13:23 -0000 1.168
+++ src/main/http_request.c 9 May 2003 18:01:06 -0000
@@ -288,7 +288,7 @@
}
else {
#if defined(EACCES)
- if (errno != EACCES)
+/* if (errno != EACCES) */
#endif
ap_log_rerror(APLOG_MARK, APLOG_ERR, r,
"access to %s failed", r->uri);
Here is some text from dev@httpd around that time, showing justification
for that change:
On Wed, 15 Jan 1997 willday@rom.oit.gatech.edu wrote:
> Submitter: willday@rom.oit.gatech.edu
> Operating system: Solaris 2.x, version:
> Version of Apache Used: 1.1.3
> Extra Modules used:
> URL exhibiting problem: agent_log_module referer_log_module
config_log_module status_module
>
> Symptoms:
> --
> If a directory has insufficient perms (700), apache will report in
the error_log that "stat() returned u\
nexpected error[13]" for _each_ possible index file in
srm.con:DirectoryIndex. Errno 13, according to /us\
r/include/sys/errno.h, is EACCES "Permissio
n denied". This tends to fill up the error_log unnecessarily, and more
important error messages get lost \
in the noise. I would imagine the code should check to see if the
errno=EACCES, and just return FORBIDDEN\
, without logging an error.
Anybody want to see if backing out the change still results in multiple
error log entries for a directory listing?
Re: 403's not getting logged?
Posted by Joshua Slive <jo...@slive.ca>.
On Fri, 9 May 2003, Rich Bowen wrote:
> I'm experiencing a should-not-happen condition in apache 1.3.27, and
> wondered if anyone else could verify for me. In the case of a 403
> error caused by incorrect directory permissions, there is no error
> log entry. If the file is unreadable, the 403 goes in the error log.
> But if the directory has bogus permissions, there's no entry.
> This is on 1.3.27 I've tested this on 2 servers so far, and it seems
> consistent.
Yes, this is a very longstanding and very irritating omission. I don't
think I would be exagerating if I said this was the source of hundreds of
confused queries to the users mailing list and newsgroup.
I browsed through the default handler a while back trying to figure out
where this error was getting dropped, but I ran out of time and never got
back to it. Someone who knows the code better could probably find it
faster.
Joshua.