Not logged in. · Lost password · Register
Forum: General Help and Support Installation and Configuration RSS
selinux ACLs for write access, and php's is_writeable() function -- can't work?
install.php fails due to access error in /data/ directory, but apache/php has access via ACL
Page:  1  2  next 
Avatar
justjed #1
Member since Jan 2017 · 12 posts · Location: DM79MO
Group memberships: Members
Show profile · Link to this post
Subject: selinux ACLs for write access, and php's is_writeable() function -- can't work?
I'm trying to install DokuWiki in an environment where the server admin doesn't want to chown -R apache:apache for the DokuWiki directory tree, and (so far) hasn't shown interest in using the PHP-FPM plugin to run scripts as the script owner. His approach has been to grant write access using a selinux ACL. OS is CentOS Linux release 7.6.1810 (Core). DokuWiki 2018-04-22a.

The docs at https://secure.php.net/manual/en/function.is-writable.php don't really address this, but there's a contributed note mentioning a way to have is_writeable() use GID instead of UID, so that implies that php is doing only a user ID check against the directory / file permissions.

I'm reluctant to comment out the check in install.php, as I've found a few other instances of is_writable() in the php code.

Am I correct that is_writeable() doesn't properly involve ACL permissions? I did find a couple really old bug reports against PHP for this, but nothing recent.

Advice appreciated.
Any sufficiently advanced technology is indistinguishable from a yo-yo -- Enoch Root
Avatar
schplurtz (Moderator) #2
Member since Nov 2009 · 437 posts · Location: France, Finistère
Group memberships: Global Moderators, Members
Show profile · Link to this post
There is no such thing as selinux ACL. selinux uses rules to apply a policy. Linux filesystem implements posix ACL. Selinux can't give you access to a filesystem object if the filesystem itself does not grant you access, because Linux first checks file permissions (with or witout posix ACL) and then checks selinux rules. However, selinux can deny access to parts of the filesystem where you usually have access. Usually, selinux makes sure that the webserver can only accesses properly labelled files in a particular directory set.

So I understand that your sysadmin uses both posix ACL and sellinux. If not, discard my answer.

is_writable, on php 7.0 Debian linux stretch (9.x) cli SAPI,  works fine with posix ACL (believe me, or see my tests below)

As for selinux, I'd bet that php does not check selinux.

I'm reluctant to comment out the check in install.php, as I've found a few other instances of is_writable() in the php code.
You'd have to check and change all of them. maintenance over time would be a nightmare.

Am I correct that is_writeable() doesn't properly involve ACL permissions?
no. but probably correct for selinux, but selinux shouldn't matter anyway.

In the end, with standard selinux policy that just makes sure the webserver does not try to access files outside its directories (provided that dokuwiki files are correctly labelled), and correct ACL, everything should be fine for is_writable. If is_writable reports a file or dir as beeing writable but, in the end, the file is not writable, then there is problem either with selinux (file labelling or bad rules) or ACL. This kind of settings, though a bit difficult to set up, should work.


is_writable and ACL check :
root@computer:/home# mkdir a
root@computer:/home# ll -d /home/a
drwxr-xr-x 2 root root 19 déc.  14 07:03 /home/a
root@computer:/home# cat >a/iw.php <<'EOH'
<?php
if(is_writable(__DIR__)) { echo "yes\n" ; } else { echo "no\n"; }
if(is_writable(__FILE__)) { echo "yes\n" ; } else { echo "no\n"; }
EOH
root@computer:/home# su -s /bin/bash nobody  -c 'php /home/a/iw.php'
no
no
root@computer:/home# setfacl -R -m u:nobody:rwx /home/a
getfacl a a/iw.php
# file: a
# owner: root
# group: root
user::rwx
user:nobody:rwx
group::r-x
mask::rwx
other::r-x

# file: a/iw.php
# owner: root
# group: root
user::rw-
user:nobody:rwx
group::r--
mask::rwx
other::r--

root@computer:/home#root@computer:/home# su -s /bin/bash nobody  -c 'php /home/a/iw.php'
yes
yes
root@computer:/home#
This post was edited on 2018-12-14, 08:25 by schplurtz.
Avatar
justjed #3
Member since Jan 2017 · 12 posts · Location: DM79MO
Group memberships: Members
Show profile · Link to this post
Thank you for the clarification. Yes, both selinux and ACLs are in use. In re-reading my post, I see I manged to omit the critical part of the description. install.php exits with a message complaining about the data/ dir not being writeable. With no error messages in the Apache logs, I can't tell what the underlying reason for that is.

Apache is running as user/group apache:apache, and the document_root for Dokuwiki is not owned by apache. Access for Apache to that directory is granted via a selinux context/labels and ACL. The sysadmin claims he has tested this and it works for him.
Any sufficiently advanced technology is indistinguishable from a yo-yo -- Enoch Root
This post was edited on 2018-12-14, 15:04 by justjed.
Avatar
Michaelsy #4
Member since Jun 2015 · 922 posts · Location: Düsseldorf, Germany
Group memberships: Members
Show profile · Link to this post
Quote by justjed:
With no error messages in the Apache logs, I can't tell what the underlying reason for that is.

Maybe you receive a meaningful error message if you write a small PHP script that performs such a write access?
By Patreon.com a few eurons can be fed into the code phasers of
the DokuWiki engine. Besides, Andi's posts are worth reading.
This post was edited on 2018-12-14, 17:49 by Michaelsy.
Avatar
schplurtz (Moderator) #5
Member since Nov 2009 · 437 posts · Location: France, Finistère
Group memberships: Global Moderators, Members
Show profile · Link to this post
In reply to post #3
Ah, I see. The exact oposite of what I thought initially ;-)

As I said, this situation involves two stages : ACL first, then selinux.

The sysadmin claims he has tested this and it works for him
Yet, something is not OK. Your sysadmin seems to be pretty sure that PHP can write, but PHP thinks it cannot.
Either PHP is wrong, and you have no choice but to patch the code and to report a bug on DokuWiki github, or PHP is right and your sysadmin is wrong.

As Michaelsy suggested, if possible, write a little test. This might give you a lead.
If it's selinux fault, there must be some messages in selinux audit log. See for example https://access.redhat.com/documentation/en-us/red_hat_ente…

Finally, if you need to find out wether PHP is right or wrong : Can you, or your sysadmin, check again the ACL first ?
getfacl /where/your/dokuwikifiles/are/.
getfacl /where/your/dokuwikifiles/are/data

If it appears write permission is granted to apache:apache, then check selinux.

Unfortunately, I can't help much with selinux, because I'm not an selinux expert myself. I just know the basis.
what is the result of ls -Z in dokuwiki directory ? are you sure your files (or at least conf, data, lib/plugins and lib/tpl) have the correct context ? See those two questions on stackexchange :
349852/selinux-prevents-httpd-write-files
50639/httpd-cant-write-to-folder-file-because-of-selinux

If everything is ok, then it is probably PHP's fault, unless someone else sees where I am wrong and suggest a better explanation...

Good luck.
Schplurtz.
In cases of major discrepancy it's always reality that's got it wrong.
Avatar
justjed #6
Member since Jan 2017 · 12 posts · Location: DM79MO
Group memberships: Members
Show profile · Link to this post
In reply to post #4
Quote by Michaelsy:
Maybe you receive a meaningful error message if you write a small PHP script that performs such a write access?

Oh, I should've tried that. I've not done any meaningful IT work in a couple decades - quite rusty. Anyways, I get a permission error on the fopen(), but no specifics. If other options come to naught, I'll have to dig into PHP to see about enhancing the error reporting.

getfacl /where/your/dokuwikifiles/are/.
getfacl /where/your/dokuwikifiles/are/data
document_root:
user::rwx
user:apache:rwx
group::rwx
mask::rwx
other::r-x
default:user::rwx
default:user:apache:rwx
default:group::rwx
default:mask::rwx
default:other::r-x
data/
user::rwx
user:apache:rwx                 #effective:r-x
group::rwx                      #effective:r-x
mask::r-x
other::r-x
default:user::rwx
default:user:apache:rwx
default:group::rwx
default:mask::rwx
default:other::r-x

Hmmm, that "effective" comment could be the pointer to the issue. I found an article mentioning that getfacl adds this comment to indicate the "effective" result. I will have to point this out to the sysadmin. I haven't messed with ACLs since VMS 4.0, in 1984; I bet Posix ACLs are a bit different. :-D

what is the result of ls -Z in dokuwiki directory?

The unconfined_u:object_r:httpd_sys_rw_content_t:s0 is there, as in the 1st StackExchange example, but not the httpd_sys_rw_content_t. So, a second thing to suggest.

Thank you both.

Addendum: my test script to open a file for write works in document_root, but not data/ so I think it must be the difference in the ACL, as in "#effective: r-x".
Any sufficiently advanced technology is indistinguishable from a yo-yo -- Enoch Root
Avatar
schplurtz (Moderator) #7
Member since Nov 2009 · 437 posts · Location: France, Finistère
Group memberships: Global Moderators, Members
Show profile · Link to this post
I haven't messed with ACLs since VMS 4.0, in 1984; I bet Posix ACLs are a bit different. :-D
So you have experienced total happiness ! I wish I had the opportunity to work on such machine.

user:apache:rwx                 #effective:r-x
You found the problem

Can your sysadmin run something like this ?
chmod -R g+w /where/the/files/are
or that ?
setfacl -R -m m:rwx -m d:m::rwx /where/the/files/are

What happens is that when there are posix ACL, the group permissions bits map to the ACL mask whose goal is to  remove permissions on ACL entries, no matter what they are in the first place (thus the "effective"). The designers of ACL thought this was the thing to do; and this has been constantly giving headaches to every sysadmin who uses those pesky ACL. Anytime something changes the group permission, it in fact changes the ACL mask and thus removes rights for almost anyone.

As a well known consequence, posix ACLs usually break when you import files into an ACL controlled directory, because most tool will preserve permission bits which are generally 755 (not 775) on directories, totally unaware that it creates the mask r-x which will remove write permission on other ACL entries. Patatras !

unconfined_u:object_r:httpd_sys_rw_content_t:s0
This is ok for me. there is the important rw part. If not, you would not have been able to create a file.
Avatar
schplurtz (Moderator) #8
Member since Nov 2009 · 437 posts · Location: France, Finistère
Group memberships: Global Moderators, Members
Show profile · Link to this post
Subject: use dw downloader
Just thinking of that : If you can, move all your current files out of the way, and try to use the dokuwiki downloader.

It should work because it's the apache daemon that will be creating the files and directories, and the mask does not apply to the owner.
This post was edited on 2018-12-15, 08:43 by schplurtz.
Avatar
justjed #9
Member since Jan 2017 · 12 posts · Location: DM79MO
Group memberships: Members
Show profile · Link to this post
Sorry for the delay in getting back to you. The SA didn't get back to me with any attempts/results for changing the ACLs. Instead, finally, what I got was a whole new server instance, no ACLs, and an SELinux context which I think isn't necessary, but also doesn't appear to do any damage either. I have sudo, so now can chown -R apache;apache the whole DOCUMENT_ROOT.

However, CentOS 7.5.1804 has a 5.4 version of PHP, so install.php won't proceed. That's a whole nother problem, and I'd rather be on a LTS release of Ubuntu Server. Oh well -- not my call, at least not yet.

Thanks for helping.
Any sufficiently advanced technology is indistinguishable from a yo-yo -- Enoch Root
Avatar
schplurtz (Moderator) #10
Member since Nov 2009 · 437 posts · Location: France, Finistère
Group memberships: Global Moderators, Members
Show profile · Link to this post
Hi,
This is bad news and good news.
bad because I'm pretty sure that the recommended chown/setfacl command would have solved your problems, and you'd be already enjoying DW by now.
The good aspect is that you can install a new PHP version now. I don't do CentOS, so I can't help for that, but I'm confident you'll find PHP RPMs that provide a suitable PHP version.
Avatar
turnermm (Moderator) #11
Member since Oct 2009 · 4642 posts · Location: Canada
Group memberships: Global Moderators, Members, Super Mods
Show profile · Link to this post
If at all possible try to use the dokuwiki downloader and avoid using the centos package manager (yum) for installing a new  Dokuwiki.  That is, if it still uses a file structure which is much the same as that found in Ubuntu and Debian.  It's been some time since I looked at it but it may also be as restrictive as the debian/ubuntu.  So before proceeding, check the ubuntu/debian pages in dokuwiki.org. On the positive side, if you do use yum, and don't like what you get, you can always uninstall.
Myron Turner
github: https://github.com/turnermm
plugins, templates: http://www.mturner.org/devel
Avatar
turnermm (Moderator) #12
Member since Oct 2009 · 4642 posts · Location: Canada
Group memberships: Global Moderators, Members, Super Mods
Show profile · Link to this post
I have to backtrack.  If you have only php 5.4, you might have to stay with yum since current versions of dokuwiki need 5.6 or later. 

For a manual install from the command line, you should be able to use: Release 2017-02-19e “Frusterick Manners”.  Here is a link to the distro archive:
    https://download.dokuwiki.org/archive
What you need is 2017-02-19e.


This Wordpress article is useful, beginning with step 2.
       https://linuxcluster.wordpress.com/2014/07/16/installing-d…
Myron Turner
github: https://github.com/turnermm
plugins, templates: http://www.mturner.org/devel
Avatar
MartinR #13
Member since Jul 2015 · 141 posts · Location: UK
Group memberships: Members
Show profile · Link to this post
For clarity: under CentOS 7 you'll have to put up with PHP 5.4.16.  CentOS 8 will move to a later version, but enterprise distros strive mightily to keep versions constant.  Updating PHP will break other things, if memory serves me aright that includes yum.  You can install PHP 5.5.21 from the SCLO repository, but you will need to use the software packages system to enable it for DW.

I've searched the standard repositories for \*oku\* and have found nothing relevant.  I think that yum (other than for PHP) is a red herring, you just need to install Frusterick Manners using DW's installer.  I'm fairly certain that's what I did, and I'm running DW Release 2017-02-19e under CentOS 7.6.1810 fully patched as of today.
Avatar
schplurtz (Moderator) #14
Member since Nov 2009 · 437 posts · Location: France, Finistère
Group memberships: Global Moderators, Members
Show profile · Link to this post
Quote by MartinR:
Updating PHP will break other things, if memory serves me aright that includes yum.
Hum, I don't like sentences like this. It sounds like "if you do this, your computer will stop to function". PHP is a non essential package, it is necessarily possible to uninstall the system PHP and install a third party package with another version.

Package managers are extremely robust softwares, because they perform essential tasks. yum and rpm are no exception. They won't "break" easily. That said, care must be taken when installing 3rd party software that is does not want to replace some more essential parts of the system.

Eventually, you can get conflicts between packages, and resolving those conflicts can be very tricky and scary or nearly impossible, depending of your skill and courage. You may have to remove the offending package (and tens of other packages) then do whatever it was you wanted to do in the first place (update, install something else etc...), then go find some PHP packages that don't create issues. That's just the usual troubles people administering computers face. It can become time consuming.

The real difficulty is to find a package repository that one can trust. repositories that provide high quality, uptodate packages and that will be doing so for a long time, because you need to sure there will be security fixes and compatible packages, not only in three months from now, but also in 4 or 5 years. Centos 7 end of line  is 2024, I just can't believe there does not exist such repositories.
Avatar
MartinR #15
Member since Jul 2015 · 141 posts · Location: UK
Group memberships: Members
Show profile · Link to this post
Apologies, wrong "P".  Under RHEL/CentOS it is Python that can't be removed or updated.  Trying results in several hundred lines of dependencies and finally Error: Trying to remove "yum", which is protected.

If the OP is running an enterprise machine where stability is important then I would be very cautious about bringing in packages from sources other than CentOS, EPEL and ELRepo.  Looking at my server at home (I've had to give up work after 35 years in operations and programming so can't access my work cluster) I've only added Adobe and Nux to the basic list.  If you want to play with the latest bleeding edge on a personal machine, then perhaps Fedora would be a better choice.  I've just spun up a F29 VM and the standard version of PHP is 7.2.14
Close Smaller – Larger + Reply to this post:
Verification code: VeriCode Please enter the word from the image into the text field below. (Type the letters only, lower case is okay.)
Smileys: :-) ;-) :-D :-p :blush: :cool: :rolleyes: :huh: :-/ <_< :-( :'( :#: :scared: 8-( :nuts: :-O
Special characters:
Page:  1  2  next 
Go to forum
Imprint
This board is powered by the Unclassified NewsBoard software, 20150713-dev, © 2003-2015 by Yves Goergen
Current time: 2019-06-17, 02:58:59 (UTC +02:00)