Bug 250910

Summary: Httpd Not Mapping to User Directories
Product: [Fedora] Fedora Reporter: Dustin <d_blagg>
Component: system-config-httpdAssignee: Phil Knirsch <pknirsch>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 9CC: jorton, rvokal, triage
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-07-14 18:16:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
httpd.conf file used to configure server none

Description Dustin 2007-08-05 02:28:18 UTC 
Description of problem:

The httpd daemon is not translating the user directory URL to the correct
directory as defined in the httpd.conf file.  Instead it is interpreting the
tilde (~) as a literal character and mapping back to the WWW root directory.

i.e.  Using URL http://www.my-domain.com/~user, httpd resolves this as

    /var/www/html/~user
and not
    /home/user/public_html

This has been tested with both SElinux on and off with the same result. The
resulting error in the httpd error.log file is:

    [Sun Aug 05 11:19:51 2007] [error] [client XXX.XXX.XXX.XXX] File does not
exist: /var/www/html/~user

Verifying that the SELinux settings are correct and the directory permissions
are correct:

Directory permissions = 
    a) drwxr-xr-x 6 root root 4096 2007-06-02 16:26 /home
    b) drwx--x--x 42 user user 4096 2007-06-04 19:46 /home/user/
    c) drwxr-xr-x 2 user user 4096 2007-06-04 19:46 /home/user/public_html/

The SElinux types are =

  user_u:object_r:httpd_sys_content_t for the directory /home/user/public_html/

Checking that user directories is enabled in SElinux = 

    [root@undine ~]# getsebool httpd_enable_homedirs
    httpd_enable_homedirs --> on

Checking that the user_dir module is loaded in apache using phpinfo() script
produces the following results:

core prefork http_core mod_so mod_auth_basic mod_auth_digest mod_authn_file
mod_authn_alias mod_authn_anon mod_authn_dbm mod_authn_default mod_authz_host
mod_authz_user mod_authz_owner mod_authz_groupfile mod_authz_dbm
mod_authz_default util_ldap mod_authnz_ldap mod_include mod_log_config mod_logio
mod_env mod_ext_filter mod_mime_magic mod_expires mod_deflate mod_headers
mod_usertrack mod_setenvif mod_mime mod_dav mod_status mod_autoindex mod_info
mod_dav_fs mod_vhost_alias mod_negotiation mod_dir mod_actions mod_speling
mod_userdir mod_alias mod_rewrite mod_proxy mod_proxy_balancer mod_proxy_ftp
mod_proxy_http mod_proxy_connect mod_cache mod_suexec mod_disk_cache
mod_file_cache mod_mem_cache mod_cgi mod_auth_mysql mod_security2 mod_unique_id
mod_perl mod_php5 mod_proxy_ajp mod_python mod_ssl

Version-Release number of selected component (if applicable):
    httpd-2.2.4-4.1.fc7.rpm
    httpd-2.2.4-4.1.fc7.src.rpm

How reproducible:


Steps to Reproduce:
1. httpd.conf file with the following entry =

    <IfModule mod_userdir.c>
    UserDir public_html
    </IfModule>

    <Directory /home/*/public_html/>
    AllowOverride FileInfo AuthConfig Limit
    Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
    <Limit GET POST OPTIONS>
    Order allow,deny
    Allow from all
    </Limit>
    <LimitExcept GET POST OPTIONS>
    Order deny,allow
    Deny from all
    </LimitExcept>
    </Directory>

2. Disk set up as follows (or similar) = 

    /dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)
    proc on /proc type proc (rw)
    sysfs on /sys type sysfs (rw)
    devpts on /dev/pts type devpts (rw,gid=5,mode=620)
    /dev/sdb1 on /home type ext3 (rw)
    /dev/sda1 on /boot type ext3 (rw)
    tmpfs on /dev/shm type tmpfs (rw)
    none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
    sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)

NOTE: The /home directory is on a separate partition from the main volume
despite the logical volume spanning /dev/sda and /dev/sdb.

3. Create a user and have a public_html directory created in their home
directory.  Set the appropriate permissions to allow world read and execute
privileges.

4. Change SElinux policy for HTTPD to allow user home directories.

5. Create simple index.html file in the user public_html directory.

6. Open browser and try to navigate to user directory.
  
Actual results:

Receive "404 Not Found" error and httpd tries to resolve the URL to the Document
Root directory with ~user

Expected results:

Httpd to resolve the http://www.my-domain.com/~user request to the correct
directory on the server.  (e.g. /home/user/public_html)

Additional info:
Comment 1 Dustin 2007-08-05 02:28:19 UTC 
Created attachment 160707 [details]
httpd.conf file used to configure server
Comment 2 Joe Orton 2007-08-09 15:48:16 UTC 
What SELinux warnings do you get (audit.log)?
Comment 3 Dustin 2007-08-10 23:25:41 UTC 
I receive no SELinux warnings in the audit.log.  Nothing shows in the
setroubleshootd.log file either.  The only entries found are the following httpd
log files:

access_log =
XXX.XXX.XXX.XXX - - [11/Aug/2007:09:11:42 +1000] "GET /~user HTTP/1.1" 404 335
"-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.5) Gecko/20070718
Fedora/2.0.0.5-1.fc7 Firefox/2.0.0.5"


error_log = 
[Sat Aug 11 09:11:42 2007] [error] [client XXX.XXX.XXX.XXX] File does not exist:
/var/www/html/~user


modsec_audit.log =
--91f64860-A--
[11/Aug/2007:09:21:04 +1000] oPzHWX8AAAEAAALLF1cAAAAD XXX.XXX.XXX.XXX 45624
YYY.YYY.YYY.YYY 80
--91f64860-B--
GET /~user HTTP/1.1
Host: www.my-domain.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.5) Gecko/20070718
Fedora/2.0.0.5-1.fc7 Firefox/2.0.0.5
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-au,en;q=0.7,en-us;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cache-Control: max-age=0

--91f64860-F--
HTTP/1.1 404 Not Found
Content-Length: 335
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

--91f64860-H--
Apache-Error: [file "/builddir/build/BUILD/httpd-2.2.4/server/core.c"] [line
3633] [level 3] File does not exist: /var/www/html/~user
Stopwatch: 1186788064151385 3531 (481 3046 -)
Producer: ModSecurity v2.1.1 (Apache 2.x)
Server: Apache/2.2.4 (Fedora)

--91f64860-Z--
Comment 4 Dustin 2007-09-21 14:00:49 UTC 
Found out what the problem is.  In the directory /etc/httpd/conf.d, there was a
file system-config-httpd.conf which had the UserDir directive set to "disable".
This setting was overriding the values set in the httpd.conf file in
/etc/httpd/conf/ directory.

After changing the UserDir directive to public_html in the
system-config-httpd.conf, apache is now doing what it should be.

Maybe if this setting is either removed from the system-config-httpd.conf or the
system-config-httpd applet allows the user to toggle/configure this setting in
there this issue could be addressed.
Comment 5 Joe Orton 2007-10-02 09:21:36 UTC 
I agree, it seems like a recipe for confusion.
Comment 6 Bug Zapper 2008-05-14 13:52:28 UTC 
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 7 Andreas Loening 2008-05-19 21:42:18 UTC 
Ran into this exact problem as well on a fresh install of Fedora 9. Initially
ran system-config-httpd to try to configure the httpd server. However, there was
no option to enable the UserDir feature with system-config-httpd, so I did what
I thought was the obvious thing to do, and edited httpd.conf to try to enable
UserDir. After beating my head against the wall for a long period, I found this
helpful bug entry, and realized that system-config-httpd.conf was the problem.

I would suggest that the UserDir configuration needs to go in one of these .conf
files, not both. As it is right now, the feature needs to be enabled in both
files for UserDir to work.
Comment 8 Bug Zapper 2009-06-09 22:44:31 UTC 
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 9 Bug Zapper 2009-07-14 18:16:12 UTC 
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.