Permissions on Linux
-
I'm attempting to install some shitty OSS called TestLink, mostly because it's the only FOSS I can find that does what it does and we're having trouble convincing our bosses to spend money on things they claim to prioritize.
I'm using a Fedora 20 VM as a sandbox, since our real linux servers are Red Hat 5 or 6. After installing a LAMP stack, creating a database for the software to use, running a SQL install script to make the table structure, and creating a few extra folders as instructed, I connect to the software to run the "installer".
And I'm stopped at the prerequisites. One of the folders is "not writable" despite being owned by user apache and group apache AND being set to 777 anyway:
Okay, so I change user to apache to see if I can get any more interesting information when I try to write to the folder....
WTF? How are they testing write permissions badly?! Just attempt to write to the folder and see if it fails!
-
This topic needs more @blakeyrat.
-
And @morbiuswilters just because.
-
A quick google search shows that this is a common problem. Especially on windows, which isn't surprising. But it looks like there are some symlink shenanigans possibly going on in the configuration.
-
And just for bonus points, there are configuration options that can make PHP shit itself if trying to access 777 permissioned things.
-
Looks like they are using http://fr2.php.net/is_writable to check if the directory is writable. So maybe TRWTF is PHP?
-
There you go. Once again, TRWTF is PHP.
-
Especially on windows
I'm on Fedora Linux.
it looks like there are some symlink shenanigans
The directory doesn't look like a symlink when I ll'd it... but I'm not too familiar with the various types of symlinks.
Looks like they are using http://fr2.php.net/is_writable to check if the directory is writable.
Any idea how that's gone so terribly, terribly wrong? >.>
-
VinDuv said:
Looks like they are using http://fr2.php.net/is_writable to check if the directory is writable.Any idea how that's gone so terribly, terribly wrong? >.>
"Keep in mind that PHP may be accessing the file as the user id that the web server runs as (often 'nobody')."
-
Why should that be a WTF? Not letting PHP have full control of shit is a good thing.
-
I'm on Fedora Linux.
I know...but that may imply deeper problems than actual permission settings.
Any idea how that's gone so terribly, terribly wrong? >.>
I saw a comment there about them doing UID checking (nobody, as already pointed out).
Why should that be a WTF? Not letting PHP have full control of shit is a good thing.
Yes, and I never thought anyone should. But now we need something like an is_real_writable() function.
-
Except it's not something PHP gets control over anyway. It's what Apache gives it access to via suexec.
-
Keep in mind that PHP may be accessing the file as the user id that the web server runs as
Yes, the user "apache". I guess I skipped the part where I checked that the httpd process was running as "apache", but I figured it was understood why I was checking that user.
It's what Apache gives it access to via suexec.
This might be the key. How can I find out if PhP is being executed as a different user than apache's main user process?
(Not that it should matter, because everything's 777, but if it's confusing PhP that might be the problem)
-
Except it's not something PHP gets control over anyway. It's what Apache gives it access to via suexec.
You've lost me. If the directory is writable by everyone, how does Apache take that away?
-
Good question.
Who owns the folder you're trying to write to, and is it the same user that owns the file you're trying to execute?
(it's a complete clusterfuck to be honest)
-
It's voodoo. I don't actually know. I just shout at the host to make it fucking work
-
As you can see in the first screenshot, it's 777 apache apache. There was no files in it, I suspect it's meant to be some kind of temporary dumping ground for the application to use but I'm not 100% sure. I made a few files inside when testing permissions, but that's all.
-
Like I said, where is is_real_writable() when you need it?
-
It's fucking 6 AM! Fuck.
-
-
The write may be blocked by SELinux (which I think is on by default in Fedora), not by ordinary permissions.
-
I made a test page and echo'd exec('whoami') and came up with "apache", so it's not the apache-making-php-run-as-another-user thing.
The write may be blocked by SELinux
How can I tell?
-
How can I find out if PhP is being executed as a different user than apache's main user process?
Maybe the sample on http://fr2.php.net/manual/en/function.posix-getuid.php can help. (You can use
getent passwd [uid]
to convert the user ID to a username)You can also change line 934 of
lib/functions/configCheck.php
fromif(!file_exists($the_d))
to
if(false)
and see if it works...
-
The write may be blocked by SELinux (which I think is on by default in Fedora)
It is. I gave up on trying to use Fedora as a development environment because I couldn't figure out settings that would let me work successfully.
-
Also came up apache
-
I assume Red Hat also has this SELinux thing? We're mandated to use Red Hat for linux servers in our company, because something something enterprise, which is why my local sandbox is fedora.
-
It is. I gave up on trying to use Fedora as a development environment because I couldn't figure out settings that would let me work successfully.
This. Last time I used Fedora I ended up opening the SELinux control panel and disabling the whole thing since it caused too much interference.@Yamikuronue You can probably try this... (It’s always possible to reenable it afterwards)
-
You might have more luck with CentOS, as it is based on RHEL. New Fedoras will be much newer. I hate SELinux.
-
I can dismantle whatever I want in my sandbox, but that means it'd be a no-go putting it on the real server I'm sure. Middleware doesn't take kindly to my disabling the security on our boxes >.>
-
I assume Red Hat also has this SELinux thing? We're mandated to use Red Hat for linux servers in our company, because something something enterprise, which is why my local sandbox is fedora.
I suspect so. It's probably not too difficult to figure out the permissions. I gave up after a couple of hours of (various) problems and went back to Ubuntu. I was only trying out Fedora to get experience of another distribution, so I didn't have much of an incentive to get everything working.
-
New Fedoras will be much newer
Yeah, I had no idea we were that far behind in Red Hat versions since the whole idea of having linux servers is still in beta for us, so I just grabbed the latest fedora...
-
You could just try disabling the SELinux just to see if it is really the culprit. They also have a page that tells you where the "Access denied" messages go at http://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/chap-Security-Enhanced_Linux-Troubleshooting.html .
The correct solution would probably be to set a extended file attribute allowing apache to write to it. The description of the policies and extended file attributes is at: http://fedoraproject.org/wiki/SELinux/apache . God knows which one it is.
-
Aha!
So at least we found the culprit....
-
TRWTF is SELinux?
-
Having had to deal with it years ago, I could have told you that.
While it sounds like a good idea on paper, it's more of a nightmare to get working, particularly if you aren't getting paid to do it.
Plus, it's a feature written by the NSA...
However, as long as we're on the topic of Linux permissions, let me introduce another WTF to the equation: Linux has a second permissions system for the filesystem.
-
However, as long as we're on the topic of Linux permissions, let me introduce another WTF to the equation: Linux has a
secondthird permissions system for the filesystem.FTFY.
SELinux is enabled by default on some distributions, so people are using it (even if they don't know it). Has anyone ever actually used the ACL system?
-
I didn't think SELinux enforced the ACL system. I would have gone into more detail on the ACL system in my previous post, but I got called away from my desk.
Anyway....
Basically, as reverendryan mentioned, Linux also supports ACLs. However, they're so infrequently used that most people don't know that they exist. In fact, Ubuntu (and other Linux distros?) doesn't even install the tools to view/modify the ACLs by default.
These ACLs don't show up in
ls
and other tools... they're basically totally invisible to you unless you use thegetfacl
command. However, the filesystem will still enforce them even if you don't know about them.
-
SELinux contexts are invisible unless you remember to
ls -Z
.What Linux needs is a fourth file permissions system. Oh wait, apparmor.
Fifth! What Linux needs is a fifth file permissions system. Right now it's entirely too easy to not lock myself out of my files.
-
Well, at least
ls
has support for seeing SELinux contexts. While the program to view ACLs and manually modify them isn't installed by default, I'm pretty sure the API is...
-
The solution:
chcon -t httpd_sys_content_rw_t templates_c
-
As it seems you've found it, I don't get to be cool and provide a useful answer.
But for anyone who comes along later, the easiest way to tell if SELinux is on is to issue:
# getenforce
And to turn SELinux off until reboot, you can use:
# setenforce 0
(For clarity, the setenforce command definitely requires root/sudo permissions. I don't know for sure if getenforce does or not, but by the time I'm troubleshooting something like this, I'm usually on an elevated user).
In RHEL based distributions (including Fedora and CentOS), the file that controls SELinux state at boot time is /etc/sysconfig/selinux. Changes to this file do not effect the system until reboot. Using only setenforce will not persist across reboots.
-
The solution:chcon -t httpd_sys_content_rw_t templates_c
Bookmarked, in case I have the misfortune to deal with RHEL derivatives some time in the future.
-
You can also be kind of lazy and use chcon recursively and referencing something that has the right context (like the default /var/www/html directory) to fill in the context for files you just put in there and SELinux is having a snit fit over:
http://linux.die.net/man/1/chcon
The short syntax would be along the lines of:
# chcon -R --reference=/var/www/html /var/www/html/templates_c
-
I think it's a bad error message. Tighten the permissions down, so its not writable by anybody but Apache.
Edit: Oh. SELinux.
-
Ahhhh SELinux. Unless you yourself ARE the NSA, you almost certainly do not need that level of security. Just turn it off permanently. Or you can take the time to whitelist every single file access you may ever want to do, which is what SELinux basically is.
-
I see you have LLed and failed.
I am sad for you.
-
I don't know for sure if getenforce does or not
Nope. On my CentOS box:
Disabled``` And `getfacl` is installed, though I have no idea whether it's the default.
-
I see you have LLed and failed.
I'm just glad to see that I'm not the only one that does that!
Recently, I've been preferring "ls -latr" as in "ls, later"...at least, that's how it works out in my head.
Don't judge me.
-
I'm just glad to see that I'm not the only one that does that!
Yeah, default login shell at work is csh. Every once in a blue moon I'll have occasion to use bash for something, and discover again that I still haven't gotten around to defining my habitual aliases for bash.
-
Yeah, I just learned about ll a few weeks ago and it's already replaced ls -l in my habitual typing. Of course, I also have a batch script on windows called ls that runs a dir...