DO NOT REPLY [Bug 12822] New: - documentation suggests insecure file permissions

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12822>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12822

documentation suggests insecure file permissions

           Summary: documentation suggests insecure file permissions
           Product: Apache httpd-1.3
           Version: 1.3.26
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Minor
          Priority: Other
         Component: Documentation
        AssignedTo: bugs@httpd.apache.org
        ReportedBy: hlein@progressive-comp.com


This is minor, but: auth.html in the manual suggests file ownership/permissions 
for any htpasswd-generated password file which could be stricter.  From the 
documentation which shipped with 1.3.26 (2.0.x may be identical; I haven't 
checked): 
 
"Nevertheless, you should store the file in as secure a location as possible, 
with whatever minimum permissions on the file so that the web server itself can 
read the file. For example, if your server is configured to run as user nobody 
and group nogroup, then you should set permissions on the file so that only 
that user can read the file:" 
 
...This much I agree with.  However, the suggestion is then made: 
 
"chown nobody.nogroup /usr/local/apache/passwd/passwords 
chmod 640 /usr/local/apache/passwd/passwords" 
 
I think root.nogroup, mode 640, would be more appropriate in the above example: 
unless the webserver is meant to maintain (modify) the password file(s), there 
is no reason for the apache-user to own the file.  In fact the ownership 
suggested in the manual allows any malicious CGI, etc to modify the password 
file.  This is not too big a deal however, since malicious CGIs running as the 
apache user can already tamper with the running server child processes, bypass 
htaccess restrictions and access the filesystem directly, etc.  However, 
recommending least-privilege should do exactly that, recommend the least 
privilege necessary :)

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org