Ok, I am having issues with a script I am trying to run. I am trying to move file A from /mount/images/sync to /mount/images/logos. Both of these folders are owned by apache:root. However, when I try to move them, it won't create the subdirectories of /mount/images/logos.
When I check to see who I'm logged in as when running the script, it IS apache.
Not sure where to look to figure out what is going on. Any help would be great, and please, ask me any questions so I can give you the information you need. Not sure where to start.
EDIT EDIT EDIT
I should mention that mount/images/logos is a symbolic link pointing back to another folder, and the source folder is a mount point.
Mount Information:
mount "//192.168.1.10/design1" /home/opmasan/design1 -o ip=192.168.1.10,username=***,password=***,uid=48
You have to add...
Options +FollowSymlinks
... to the section for /mount/images in your Apache configuration.
Check the Options Directive documentation for more info.
Try to switch selinux to permissive mode.
Related
I'm very new to Yii, so please bear with me. I've an existing XAMPP setup on my MacBook, and an existing project I need to take a look at. At first the project was looking for a yii.php, so I downloaded the appropriate version (1.1.17), and extracted that to /htdocs/.
I renamed it to yii, and set the yii directory in my index.php to:
$yii=dirname(__FILE__).'/../../yii/framework/yii.php';
For reference, the project has the following directory: htdocs/cdforum/web/index.php
With everything in place, or so I think, I started up XAMPP, and loaded http://localhost/cdforum/web/index.php only to encounter the following error:
throw new CException(Yii::t('yii','Application runtime path "{path}"
is not valid. Please make sure it is a directory writable by the Web
server process.'
I have seen some people get past this by setting the yii folder's ownership via chown to their own, or apache, but the first option didn't work for me, and apache apparently is an illegal user name.
Anything else I can try?
Change your username:group in httpd.conf file of Apache:
About line ~181-182:
To your user in your Mac.
Don't change the Apache User and Group. There are very good reasons why Apache has it's own user and group. Here's a simple example of what can go wrong...
While developing you make a mistake in your app and delete files
recursively in a directory, this directory has a sym link that you
follow into your home directory and you delete everything in your home
directory. This cannot happen if the users are different.
In production if you changed the owner of the user/group to a real user account the you'd almost certainly incur the wrath of the OPS department ie you're creating a security hole, a bad one.
The correct thing to do is to do what it asks ie make the directory writable by the apache process ie use chown or chmod. If you are developing then use this, in production this is also bad...
chmod 777 ./path/to/directory
In prod the directories apache need to write to would either have group write permissions for the apache user or be be owned by the apache user. Only those directories that it requires write access to, nothing else.
I want to add new DNS on my server. I'm able to edit the file /etc/resolv.conf using vi editor.
But, when I try using PHP.. the file is not opening.
What could be the issue?
Please suggest / provide me with a solution to fix this.
Most likely your PHP is running on a different user then when you login to the server yourself. You will have read/write access to the file and PHP doesnt.
Now increasing the rights of the PHP users could cause a security issue, so I would advise against it. But you could grant the user access to that specific file only if realy needed. Check Granting Access Permission to a file to a specific user on how to do it.
You will probably need root access to modify /etc/hosts .
You can chmod 666 /etc/hosts, but this would be a security issue.
But so is running PHP under root,
and so is chowning the /etc/hosts.
So there you have 3 (insecure) solutions. With the last one being least evil.
You might also be facing a struggle with PHP accessing files if PHP is restricted to files inside a certain directory. ( http://www.php.net/manual/en/ini.core.php#ini.open-basedir )
It seems i cannot create files. When i set permissions to 777 On the folder i am trying to create a folder in then the script works fine. If the folder is set to 755, it fails. I do not know much about linux, but i am suppose to figure this stuff out. I have spent a couple hours trying stuff. Does anyone know how to make it so that apache has high enough permissions.
I know it is a permissions and apache problem, i just do not know how to fix this. I have edited the httpd.conf file, but i really do not know what i am doing... Any help? (I saved backup.)
Please stop suggesting to use 777. You're making your file writeable by everyone, which pretty much means you lose all security that the permission system was designed for. If you suggest this, think about the consequences it may have on a poorly configured webserver: it would become incredibly easy to "hack" the website, by overwriting the files. So, don't.
Michael: there's a perfectly viable reason why your script can't create the directory, the user running PHP (that might be different from Apache) simply doesn't have sufficient permissions to do so. Instead of changing the permissions, I think you should solve the underlying problem, meaning your files have the wrong owner, or Apache or PHP is running under the wrong user.
Now, it seems like you have your own server installed. You can determine which user is running PHP by running a simple script that calls the 'whoami' program installed in most linuxes:
<?php
echo `whoami`;
If all is right, you should see the username PHP is running under. Depending on your OS, this might be 'www-data', 'nobody', 'http', or any variation. If your website is the only website running, this is easy to change by changing the user Apache runs under. If you have Debian, like I tend to, you can edit the file /etc/apache2/envvars (as root), and change the value for APACHE_RUN_USER. Depending on your OS, this variable might be set in a different configuration file, so if you can't find it in /etc/apache2/envvars, try to search for the variable declaration by using:
$ grep -R "APACHE_RUN_USER=" .
From the directory all apache-config files are in.
If you're not the only one on the server, you might want to consider creating user accounts for every website, and using something like Apache2-MPM-ITK to change the RUN_USER depending on which website is called. Also, make sure that the user the PHP process is running under is the owner of the files, and the directories. You can accomplish that by using chown:
% chown theuser:theuser -R /var/www/website/
If PHP is running with it's own user, and is the owner of the files and directories it needs to write in, the permission 700 would be enough. I tend to use 750 for most files myself though, as I generally have multiple users in that group, and they can have reading permissions. So, you can change the permissions:
% chmod 0750 -R /var/www/website/
That should be it. If you having issues, let us know, and please don't ever take up any advice that essentially tells you: if security is bothering you, remove the security.
I have a similar problem but in my case I have SELinux running and it failed even with 0777 permission. Turns out I need to explicitly allow httpd to have write access on the directory using:
chcon -R -t httpd_sys_rw_content_t <PARENT_OF_MKDIR_TARGET>
SELinux Troubleshooter may have more details.
On ubuntu you edit /etc/apache2/envvars as Berry suggested.
When you change the Apache user, beware of unintended consequences. One of them is the PHP sessions that may be stored in /var/lib/php5. You may need to change the ownership of that folder too.
I have a folder in my root MAMP directory, "site". I have that symlinked to a folder in ~/Documents/Dropbox/site, so whatever happens in "site" gets transferred to Dropbox.
However, when I do this, I get a 403 forbidden error when trying to view localhost/site- is this a problem because I'm using PHP and I should fix php.ini, or is this an httpd.conf problem?
In httpd.conf, I have AllowOverride set to None.
Thanks for any answers in advance.
There's also the FollowSymlinks option in Apache, which is generally disabled by default. You can enable it by doing
Options +FollowSymlinks
This is a bit hacky, but I had this problem before and while the solution didn't necessarily make a whole lot of sense, it worked for me:
sudo su <username> to assume the user (eg, if your webserver is running as nobody, use nobody
If #1 is a user whose shell is something similar to /sbin/nologin, temporarily use usermod to change their shell to something you can use, like /bin/bash, before sudoing as them
Symlink as the user instead of root or whatever user this was done as previously
Reset any changes made in #2
Since symlinks are by default 0777, any normal process has read access provided that the destination directory is also of sufficient permissions (0644 would be fine) - for some reason Apache gave me problems with that to. Once I created the link as the user in question, it worked like a charm. HTH!
Edit: also, this almost goes without saying, but I'm assuming you verified the link yourself via a terminal to make sure that the link is correct, right?
Why would file_put_contents refuse to work for the following code?
$f = file_put_contents("files/r.js", "Some text here");
if ($f) print 1;
else print 0;
It could be a permission problem
Is the directory /files chmoded to 777? sometimes php won't allow you to access directories if they don't have enough permission. I don't know about blank errors though.
Try to see if it has enough permissions, if not, then set it to 777 and try it.
Are you using the full path on the filesystem or are you trying to use the URI? I think this PHP function expects you to give the path as the file is found on the filesystem.
Relative paths should be okay though.
You may need to make sure the file exists and that it's permissions are set to 777. Sometimes I've found that it's not enough to just have the directory permissions set to 777 but the file must also already exist.
It is because of SELINUX.
You can mark the folder as of type httpd_sys_rw_content_t with this command to enable writing to this folder.
semanage fcontext -a -t httpd_sys_rw_content_t '/files(/.*)?'; restorecon -RF '/files/'
We've experienced this, requiring a workaround (regardless of method, permissions and anything else mentioned here). When all other fixes failed, we have found it can be linked to restrictions created by SELinux.
If you’re using windows the following solution worked perfectly for me on Windows 10 running php 5.5.38
If you’re having this problem on Windows/IIS try the following:
Go to the Folder that you are trying to write to and right click it, then select properties.
Select the Security Tab
Click Edit
Click Add
Click Advanced
Click Find Now
From the list of User select IUSR and click OK
Click OK again.
The IUSR will be displayed in the top box labelled 'Group of User Names'
Select IUSR and grant necessary permissions in the 'Permissions for BATCH' list view.
Click Apply and then you are done.
The steps may be slightly different for different versions of windows. This also applies to ASP.NET though I think the users you add are the network users (NETWORK AND OR NETWORK SERVICE users) as well as the IUSR.