Description of problem: This could be a documentation bug in setroubleshoot or a bug in policy or just me being dense. Apologies if it's the latter: I'm trying to run a web application from my home directory in order to test it. It's being run via mod_wsgi which means that apache loads the code and executes it in an apache worker. SELinux denies access to the script. SEtroubleshoot tells me to set httpd_enable_homedirs to 1 I do so but the problem remains. I try setting the labels of the files from unconfined_u:object_r:user_home_t:s0 to either system_u:object_r:httpd_sys_script_exec_t:s0 or unconfined_u:object_r:httpd_user_content_t:s0 using chcon. This lets apache proceed but I have to change the label on all the containing directories up to my home directory, not just the label on the subdirectory of my home dir that I have the program I'm testing in. That seems like it's not the correct behaviour. I now have: drwxr-xr-x. badger badger unconfined_u:object_r:httpd_user_content_t:s0 /home/badger drwxrwxr-x. badger badger unconfined_u:object_r:httpd_user_content_t:s0 /home/badger/pkgdb and the same for all the contents of pkgdb. I would expect drwxr-xr-x. badger badger unconfined_u:object_r:user_home_t:s0 /home/badger drwxrwxr-x. badger badger unconfined_u:object_r:httpd_user_content_t:s0 /home/badger/pkgdb When this is turned on: # getsebool httpd_enable_homedirs httpd_enable_homedirs --> on Version-Release number of selected component (if applicable): selinux-policy-targeted-3.6.12-62.fc11.noarch.rpm
You need to label the directory in your homedir with httpd_user_content_t or httpd_sys_content_t, then it should work. public_html for example matchpathcon /home/devel/dwalsh/public_html/ /home/devel/dwalsh/public_html unconfined_u:object_r:httpd_user_content_t:s0 THen the boolean should work. The relabeling does not happen automatically, you need to do this. The boolean just allows httpd_t to search through the homedir for files labeled as httpd_*_t files. So if you chcon -R -t httpd_user_content_t /home/badger/pkgdb It should work.
It doesn't work. The script that's being accessed is /home/badger/pkgdb/sqlalchemy/pkgdb.wsgi Here's what I presently have: drwxr-xr-x. badger badger unconfined_u:object_r:user_home_t:s0 /home/badger drwxrwxr-x. badger badger unconfined_u:object_r:httpd_user_content_t:s0 pkgdb drwxrwxr-x. badger badger unconfined_u:object_r:httpd_user_content_t:s0 sqlalchemy -rwxrwxr-x. badger badger unconfined_u:object_r:httpd_user_content_t:s0 /home/badger/pkgdb/sqlalchemy/pkgdb.wsgi # getsebool httpd_enable_homedirs httpd_enable_homedirs --> on I'll attach the audit.log that's generated by just restarting httpd (no messages) and trying to hit the URL served by the script, https://localhost/pkgdb/
Created attachment 351296 [details] audit.log audit.log taken after truncating, then restarting httpd (no messages), then trying to hit the URL hit by the script.
Correction, the first time I did this, setroubleshoot told me that I didn't have the default labelling for /home/badger so I relabelled just /home/badger via restorecon. The label on /home/badger for this audit.log was:: drwxr-xr-x. badger badger unconfined_u:object_r:user_home_dir_t:s0 badger FWIW, the previous run with user_home_t:s0 seemed to have the same AVCs.
Toshio you need to put the application in a subdir of your homedir, to get the labeling to work correctly. httpd_t is allowed to read/use directories labeled httpd_user_content_t as subdirs of /home/badger not directly there. The AVC's you attached shows httpd trying to search around in the /home/badger directory, even searching the .local directory Can't you put your app in public_html/ directrory? Toshio do you want to share your entire home directory via httpd? If so you will have to add a custom policy for this. The goal of the boolean is to allow the user to share just certain directories in the homedir not the entire directory. Directories like ~/public_html Create a file called myapache.te ============================== cut ====================================== policy_module(myapache, 1.0) gen_require(` attribute user_home_type; type httpd_t; ') list_dirs_pattern(httpd_t, user_home_type, user_home_type) read_files_pattern(httpd_t, user_home_type, user_home_type) ========================================================================== # make -f /usr/share/selinux/devel/Makefile # semodule -i myapache.pp
(In reply to comment #5) > Toshio you need to put the application in a subdir of your homedir, to get the > labeling to work correctly. > Do you mean a direct subdirectory of homedir? I have it in a subdirectory of a subdirectory of homedir right now:: /home/badger/pkgdb/sqlalchemy/pkgdb.wsgi > httpd_t is allowed to read/use directories labeled httpd_user_content_t as > subdirs of /home/badger not directly there. > No scripts are directly in /home/badger. > The AVC's you attached shows httpd trying to search around in the /home/badger > directory, even searching the .local directory > Yep. I don't know why httpd is trying to do that. AFAIK, there's no reason that httpd needs to access .local > Can't you put your app in public_html/ directrory? > This should work even if the subdirectory isn't named public_html, though, right? SELinux should be operating based purely on what the subdirectory is labeled? Just to verify, I did this: $ mv /home/badger/pkgdb /home/badger/public_html $ restorecon -R /home/badger/public_html $ sudo vim /etc/httpd/conf.d/pkgdb.conf # Change the script to point to /home/badger/public_html/sqlalchemy/pkgdb.wsgi $ sudo /etc/init.d/httpd restart # Get AVC about .local $ curl https://localhost/pkgdb/ --insecure # Get AVC about .local # Get AVC about .rpmmacros # Get AVC about /var/run/pcscd.pub # Get AVC about reading user's home dirs. So I get the same thing even with the script inside of public_html. > > Toshio do you want to share your entire home directory via httpd? > No. Not at all.
Is this script doing some kind of authentication? Is the package actually working? Looks like the tool is running rpm? Might be a tool you really can not test on a home dir with selinux in enforcing mode.
(In reply to comment #7) > Is this script doing some kind of authentication? > Standard web-db stuff that should be invisible to the system it's running on. It doesn't change its unix userid, auth against pam, or anything like that. > Is the package actually working? > With SELinux off it does work. With SELinux on it doesn't work. With /home/badger labelled as httpd_user_content_t it works. > Looks like the tool is running rpm? > The tool is a python wsgi application. It imports koji. koji imports rpm. No rpm files are touched on disk. The rpm db is not intentionally touched by the application but I don't know what the koji module is doing under the hood. > Might be a tool you really can not test on a home dir with selinux in enforcing > mode. I don't know how to prove or disprove this statement ;-). Seems odd though -- all the files needed by the application reside under /home/badger/public_html/sqlalchemy/ and those are all labelled with httpd_user_content_t.
Does the app work correctly even with SELinux complaining in enforcing mode?
No. In enforcing mode the app fails.
Well I am at a loss of what this app is trying to do. You can add all the rules as custom policy until you are done testing, or run httpd_t as a permissive domain.
Okay. It seems to affect all the TurboGears with mod_wsgi apps that I've tried so far (packagedb, fedora account system), J5 reports that moksha/fedora-community may suffer from this as well. I've asked lmacken to try and reproduce it later this week and if so, he can bring you a system to try and diagnose what's wrong.
So I wrote a quick test case and comment #1 made it work. Could have something to do with some of the external scripts or what the more elaborate code does. Things such as calling out to RPM or writing to a cache might be hitting permissions issues. The thing is when the startup of a wsgi script fails you don't get much feedback so it is hard to debug. BTW I think my issues weren't SELinux related. They happened because my home directory didn't have the execute bit enabled for all users. mod_wsgi needs to be able to list the files in the directories I guess.
Created attachment 354646 [details] test wsgi app
Created attachment 354647 [details] apache config for wsgi sample
One of the things I have been thinking of adding as a boolean is htddp_read_user_content Since we have had to allow people.fedoraproject.org to read all users content. We can not rely on a user not screwing up scp xyz people.fedoraproject.org ssh people.fedoraproject.org mv xyz public_hmtl (Especially when I did it accidentally.)
added boolean in selinux-policy-3.6.23-2.fc12.noarch
Err... so is this closed WONTFIX because the boolean was reverted? Or because the boolean doesn't fix the actual problem? Or because it should have been closed RAWHIDE but you hit WONTFIX by mistake? :-)
Reopening after talking to Dan at FUDCon. We think this might be mod_wsgi doing something it doesn't need to.
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. 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 '11'. 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 11'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 11 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
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 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.