[mythtv-users] mythweb issue: data directory is not writable by apache. Please check permissions.data directory is not writable by apache. Please check permissions.

[Stephen P. Villano]

On 9/26/13 11:33 AM, Gabe Rubin wrote:
>
>
>
> On Thu, Sep 26, 2013 at 7:43 AM, Gary Buhrmaster
> <gary.buhrmaster at gmail.com <mailto:gary.buhrmaster at gmail.com>> wrote:
>
>     On Thu, Sep 26, 2013 at 4:18 AM, Gabe Rubin <gaberubin at gmail.com
>     <mailto:gaberubin at gmail.com>> wrote:
>     ...
>     > I am running fedora 17 on the new system
>
>     I presume you are aware that that version of Fedora is
>     no longer supported, right?  With Fedora, once you
>     get on the bus, be prepared to transfer to a newer
>     bus regularly as the old one is parked in the vehicle
>     recycle lot.
>
>
> I thought Fedora 17 was still supported for a bit.  The reason for the
> new system was because I needed to upgrade from Fedora 16 and could
> not do preupgrade due to a small /boot partition.  I had to just
> install it new.  Once I have things running smoothly, I will upgrade
> to Fedora 18 as I understand that is not too difficult.
>
>
>     > One issue I am
>     > having is with mythweb.  I can't seem to view anything.  When I
>     do, I get
>     > this error:
>     >
>     > Error
>     >
>     > data directory is not writable by apache. Please check permissions.
>     >
>     >
>     > However, it appears that everything is owned by apache (although
>     I seem to
>     > remember on my older system, the user was www-data or wwwdata
>     and most of
>     > mythweb was in /var/www/html).
>
>     I am guessing you are running with SELinux enabled.  If you
>     do a 'ls -Z' you are likely to see that that location is (properly,
>     from an architectural POV) protected.  /usr/share/ should
>     not be writable by apache (only readable).
>
>
> I hate SELinux and did not have it running on the last system.  Will
> need to disable it here, but unsure how.
>
> In the meantime, this is the output of the command (doesn't this mean
> apache can write to the data directory?  and is that the correct user?):
>
> [root at localhost mythweb]# ls -Z
> -rw-r--r--. apache apache system_u:object_r:httpd_sys_content_t:s0
> ChangeLog
> drwxr-xr-x. apache apache system_u:object_r:httpd_sys_content_t:s0 classes
> drwxr-xr-x. apache apache system_u:object_r:httpd_sys_content_t:s0
> configuration
> drwxr-xr-x. apache apache system_u:object_r:httpd_sys_content_t:s0 data
> drwxr-xr-x. apache apache system_u:object_r:httpd_sys_content_t:s0
> image_cache
> drwxr-xr-x. apache apache system_u:object_r:httpd_sys_content_t:s0
> includes
> -rw-r--r--. apache apache system_u:object_r:httpd_sys_content_t:s0 INSTALL
> drwxr-xr-x. apache apache system_u:object_r:httpd_sys_content_t:s0 js
> -rw-r--r--. apache apache system_u:object_r:httpd_sys_content_t:s0 LICENSE
> drwxr-xr-x. apache apache system_u:object_r:httpd_sys_content_t:s0 modules
> -rw-r--r--. apache apache system_u:object_r:httpd_sys_content_t:s0
> mythweb.conf.apache
> -rw-r--r--. apache apache system_u:object_r:httpd_sys_content_t:s0
> mythweb.conf.lighttpd
> -rw-r--r--. apache apache system_u:object_r:httpd_sys_content_t:s0
> mythweb.php
> -rwxr-xr-x. apache apache system_u:object_r:httpd_sys_script_exec_t:s0
> mythweb.pl <http://mythweb.pl>
> drwxr-xr-x. apache apache system_u:object_r:httpd_sys_content_t:s0
> php_sessions
> -rw-r--r--. apache apache system_u:object_r:httpd_sys_content_t:s0 README
> drwxr-xr-x. apache apache system_u:object_r:httpd_sys_content_t:s0 skins
> drwxr-xr-x. apache apache system_u:object_r:httpd_sys_content_t:s0 tests
>
>  
>
>     There is work in progress for the RPMFusion packages to
>     both move that cache/data directly to an architecturally
>     valid writable location, and to create appropriate SELinux
>     policies.  Until that is complete (and btw, it seems likely
>     that those packages will only be available for "supported"
>     versions of Fedora), you have a couple of choices.  The
>     sledge hammer approach would be to set SELinux to
>     permissive (or disabled).  One could also chose to change
>     the SELinux context for those files (but be aware that a
>     system wide relabel will undo your work).  A better
>     approach would be to manually reorganize and rebuild
>     mythweb to locate the files in a different location not
>     currently controlled by SELinux, and setting the
>     appropriate permissions there.
>
>     Gary
>
>
> So is the best solution to just move everything into the
> /var/www/html/ directory?
>
>
>
> _______________________________________________
>

http://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Working_with_SELinux-Enabling_and_Disabling_SELinux.html

Has some basics on SELinux, enabling, disabling and a few very basic
operations. The commands haven't changed, as SELinux has long been mature.
If you aren't aware of the pedigree of SELinux, it was started as an NSA
project to help educate developers on writing a more secure system in
order to further development toward trusted systems. I can't recall
offhand what contractor got the job, but they did a *lot* of interaction
with the user community when developing it. That eventually made SELinux
a bit more user friendly than it originally was, which believe it or
not, is saying a great deal.
And yes, I was part of that community that corresponded with the
developers on the product and offered suggestions in making such a
complex system more user friendly to the system administrator.

That said, on my home systems, I tend to disable it. For production
systems, I've kept it active and figured out what had to be changed in
the policies to keep software working. A PIA, but a necessary evil to
maintain compliance with information security policies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20130926/42c12c40/attachment.html>