<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 9/26/13 11:33 AM, Gabe Rubin wrote:<br>
</div>
<blockquote
cite="mid:CAEV0UxBs9nuvWZvE_sFAaxm9eW8tti6xR87BTkMYmdQ8UDhFxg@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Thu, Sep 26, 2013 at 7:43 AM, Gary
Buhrmaster <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:gary.buhrmaster@gmail.com" target="_blank">gary.buhrmaster@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">On Thu, Sep 26, 2013 at
4:18 AM, Gabe Rubin <<a moz-do-not-send="true"
href="mailto:gaberubin@gmail.com">gaberubin@gmail.com</a>>
wrote:<br>
...<br>
<div class="im">> I am running fedora 17 on the new
system<br>
<br>
</div>
I presume you are aware that that version of Fedora is<br>
no longer supported, right? With Fedora, once you<br>
get on the bus, be prepared to transfer to a newer<br>
bus regularly as the old one is parked in the vehicle<br>
recycle lot.<br>
</blockquote>
<div><br>
</div>
<div>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. <br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div class="im"><br>
> One issue I am<br>
> having is with mythweb. I can't seem to view
anything. When I do, I get<br>
> this error:<br>
><br>
> Error<br>
><br>
> data directory is not writable by apache. Please
check permissions.<br>
><br>
><br>
> However, it appears that everything is owned by
apache (although I seem to<br>
> remember on my older system, the user was www-data
or wwwdata and most of<br>
> mythweb was in /var/www/html).<br>
<br>
</div>
I am guessing you are running with SELinux enabled. If
you<br>
do a 'ls -Z' you are likely to see that that location is
(properly,<br>
from an architectural POV) protected. /usr/share/ should<br>
not be writable by apache (only readable).<br>
<br>
</blockquote>
<div><br>
</div>
<div>I hate SELinux and did not have it running on the last
system. Will need to disable it here, but unsure how.<br>
<br>
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?):<br>
<br>
[root@localhost mythweb]# ls -Z<br>
-rw-r--r--. apache apache
system_u:object_r:httpd_sys_content_t:s0 ChangeLog<br>
drwxr-xr-x. apache apache
system_u:object_r:httpd_sys_content_t:s0 classes<br>
drwxr-xr-x. apache apache
system_u:object_r:httpd_sys_content_t:s0 configuration<br>
drwxr-xr-x. apache apache
system_u:object_r:httpd_sys_content_t:s0 data<br>
drwxr-xr-x. apache apache
system_u:object_r:httpd_sys_content_t:s0 image_cache<br>
drwxr-xr-x. apache apache
system_u:object_r:httpd_sys_content_t:s0 includes<br>
-rw-r--r--. apache apache
system_u:object_r:httpd_sys_content_t:s0 INSTALL<br>
drwxr-xr-x. apache apache
system_u:object_r:httpd_sys_content_t:s0 js<br>
-rw-r--r--. apache apache
system_u:object_r:httpd_sys_content_t:s0 LICENSE<br>
drwxr-xr-x. apache apache
system_u:object_r:httpd_sys_content_t:s0 modules<br>
-rw-r--r--. apache apache
system_u:object_r:httpd_sys_content_t:s0
mythweb.conf.apache<br>
-rw-r--r--. apache apache
system_u:object_r:httpd_sys_content_t:s0
mythweb.conf.lighttpd<br>
-rw-r--r--. apache apache
system_u:object_r:httpd_sys_content_t:s0 mythweb.php<br>
-rwxr-xr-x. apache apache
system_u:object_r:httpd_sys_script_exec_t:s0 <a
moz-do-not-send="true" href="http://mythweb.pl">mythweb.pl</a><br>
drwxr-xr-x. apache apache
system_u:object_r:httpd_sys_content_t:s0 php_sessions<br>
-rw-r--r--. apache apache
system_u:object_r:httpd_sys_content_t:s0 README<br>
drwxr-xr-x. apache apache
system_u:object_r:httpd_sys_content_t:s0 skins<br>
drwxr-xr-x. apache apache
system_u:object_r:httpd_sys_content_t:s0 tests<br>
<br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
There is work in progress for the RPMFusion packages to<br>
both move that cache/data directly to an architecturally<br>
valid writable location, and to create appropriate SELinux<br>
policies. Until that is complete (and btw, it seems
likely<br>
that those packages will only be available for "supported"<br>
versions of Fedora), you have a couple of choices. The<br>
sledge hammer approach would be to set SELinux to<br>
permissive (or disabled). One could also chose to change<br>
the SELinux context for those files (but be aware that a<br>
system wide relabel will undo your work). A better<br>
approach would be to manually reorganize and rebuild<br>
mythweb to locate the files in a different location not<br>
currently controlled by SELinux, and setting the<br>
appropriate permissions there.<br>
<br>
Gary<br>
<br>
</blockquote>
<div><br>
</div>
<div>So is the best solution to just move everything into
the /var/www/html/ directory? <br>
</div>
</div>
<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
</pre>
</blockquote>
<br>
<a class="moz-txt-link-freetext" href="http://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Working_with_SELinux-Enabling_and_Disabling_SELinux.html">http://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Working_with_SELinux-Enabling_and_Disabling_SELinux.html</a><br>
<br>
Has some basics on SELinux, enabling, disabling and a few very basic
operations. The commands haven't changed, as SELinux has long been
mature.<br>
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.<br>
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.<br>
<br>
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.<br>
</body>
</html>