Web lists-archives.com

Re: Weird permission issue

On Thu, May 9, 2019 at 10:35 AM Richard
<inbound-lists-php@xxxxxxxxxxxxxxxxxxxxx> wrote:
> > Date: Thursday, May 09, 2019 01:03:33 +0530
> > From: Zareef Ahmed <zareef@xxxxxxxxxx>
> >
> > I think you can run through the following checklist:-
> >
> > 1. Web server is running under the same user which owns that
> > directory.
> > 2. If the owner is not the same, then please change the
> > owner using chown .
> > 3. If permissions are not the same, then change
> > permission using chmod.
> > 4. On some Linux boxes, SELinux may have been enabled,
> > and context has been set for that specific directory.
> > You can try to disable SELinux.
> >From a security perspective, these are very bad suggestions (and I
> don't think relevant to the issue at hand anyway).
> Directories and files accessible by the web server should never be
> owned, and generally not writable, by the user the server is running
> as. If they are, then if someone is able to break through - most
> likely via a poorly written script - they can control all the content
> served by the web server. System security features like SELinux
> should never be turned off simply because they are not understood. If
> context permissions are needed, then add them.
> The initial issue was described as:
>    mv /var/www/html/foo  /var/www/html/foo.old
>    mv /var/www/html/foo.new /var/www/html/foo
>    When I do that I get an error writing to the log file:
>    Error #2: fopen(/var/www/html/foo/log.txt): failed to open
>    stream: Permission denied
> without more detail, I'm going to suspect that there is something
> about the way the log file write is done that is different between
> the two scripts. It's possible that it's a selinux issue, the output
> from an "ls -lZ" would provide useful information.

Yes, it is SELinux, as if I disable it the issue goes away. But the
context is the same for both files:

-rw-rw-rw-. root root unconfined_u:object_r:httpd_sys_content_t:s0
-rw-rw-rw-. root root unconfined_u:object_r:httpd_sys_content_t:s0

It seems that SELinux is somehow tied to the inode of the original
file, no matter what the actual path is.