EDIT 01 UPDATE:
ERROR Showing UP Warning: mkdir(): Permission denied in
/var/www/html/projeto01/index.php on line 7 Sucess. Dir Created
EDIT 02
Change to FEDORA and is working.
Thank you guys
before submitting this topic I read and tried all the topics here. No success.
The environment is working great until here. Php 7.4, Apache, Mysql Workbench, Atom... i can code and select from database, everything was great.
The code is working with no error execpt it did not create the directory. :/
If i create the dir manually, return the message that it already exist.
After read a lot of topics and get help from facebook.
I did change on group polices. Not worked.
chmod on the folder, not worked.
On CENTOS the apache user is APACHE instead www:data
ls -l /var/www return:
drwxr-x---. 2 apache apache 6 Nov 16 13:19 cgi-bin
drwxrwxrwx. 3 apache apache 39 Mar 19 13:54 html
ls -l /var/www/html return:
-rw-r--r--. 1 root root 86 Mar 19 00:09 info.php
drwxrwxrwx. 2 apache apache 23 Mar 19 13:58 projeto01
ls -l /var/www/html/projeto1 return:
-rwxrwxrwx. 1 root root 148 Mar 19 15:14 index.php
Thanks for the help!
My code is:
> <?php
$name = "images";
if (!is_dir($name)) {
mkdir($name);
echo "Sucess. Dir Created.";
} else {
echo "Dir already exist. $name";
}
?>
Related
I'm having permissions problems when running the following PHP script as root:
#!/usr/bin/php
<?php
$ph = proc_open('whoami', [['pipe','r'],['pipe','w'],['file','/tmp/foo.bar', 'w']], $fds);
if ($ph) {
echo 'command output: ' . stream_get_contents($fds[1]);
proc_close($ph);
} else {
echo 'proc_open failed' . PHP_EOL;
}
The script itself runs fine if /tmp/foo.bar doesn't exist, or is owned by root. But if ownership is changed to another user, proc_open will fail regardless of permissions on the file.
SELinux is disabled, and we are not using ACLs. I'm using PHP 7.4.33 (I know it's old and unsupported, but it's a requirement for FreePBX) on Alma Linux 9.1.
Output:
$ ./test.php
command output: root
$ ls -lah /tmp/
total 12K
drwxrwxrwt. 18 root root 4.0K Dec 14 16:57 .
dr-xr-xr-x. 18 root root 4.0K Dec 14 16:48 ..
-rw-r--r-- 1 root root 0 Dec 14 16:57 foo.bar
$ chown admin /tmp/foo.bar
$ ./test.php
proc_open failed
$ chmod 777 /tmp/foo.bar
$ ./test.php
proc_open failed
$ ls -lah /tmp/
total 12K
drwxrwxrwt. 18 root root 4.0K Dec 14 16:57 .
dr-xr-xr-x. 18 root root 4.0K Dec 14 16:48 ..
-rwxrwxrwx 1 admin root 0 Dec 14 16:57 foo.bar
$ tail -2 /var/log/php.log
[14-Dec-2022 16:57:17 America/Toronto] PHP Warning: proc_open(/tmp/foo.bar): failed to open stream: Permission denied in /test.php on line 3
[14-Dec-2022 16:57:28 America/Toronto] PHP Warning: proc_open(/tmp/foo.bar): failed to open stream: Permission denied in /test.php on line 3
Even disregarding the fact that I'm root, group permissions should allow me full access to the file. So what's going on?
This is due to the permissions on the /tmp directory. When PHP tries to open the file for writing, it gets the EACCES error. From the documentation of open(2):
EACCES
Where O_CREAT is specified, the protected_fifos or protected_regular sysctl is enabled, the file already exists and is a FIFO or regular file, the owner of the file is neither the current user nor the owner of the containing directory, and the containing directory is both world- or group-writable and sticky. For details, see the descriptions of /proc/sys/fs/protected_fifos and /proc/sys/fs/protected_regular in proc(5).
/tmp has the sticky bit set so that anyone can create files there, but users can only delete their own files. Although root can bypass this deletion restriction, it can't bypass the above check in open().
Ok I tried this in a different directory than /tmp, as suggested in comments, and it worked as expected. Using that to hone my search terms I was able pretty quickly to find this U&L answer. Beginning with kernel 4.19 the fs.protected_regular kernel parameter was made available. This parameter:
Disallows open of FIFOs or regular files not owned by the user in world writable sticky directories, unless the owner is the same as that of the directory or the file is opened without the O_CREAT flag. The purpose is to make data spoofing attacks harder.
Apparently it's enabled by default. So because /tmp is world-writable and sticky, I can't touch files that aren't mine – even if I'm root. For the record, if I have to disable this feature:
sysctl fs.protected_regular=0
echo 'fs.protected_regular=0' > /etc/sysctl.d/90-writabletemp.conf
But I'll be better off trying to work around it in the code somehow.
Persumably, this is a *nix permissions question. I'm a Java dev trying to write some simple PHP code. We have a production machine running FreeBSD+Apache.
I'm trying to create a directory called 'ccc' as in '/var/www/aaa/bbb/ccc'
Directories 'aaa' and 'bbb' already exist.
This is ls -ltrh output for directory 'aaa':
drwxr-xr-x 7 root root 12K Jun 10 05:27 aaa
This is ls -ltrh output for directory 'bbb':
drwxr-xr-x 3557 858 856 116K May 28 06:15 bbb
This PHP code does not create the directory '/var/www/aaa/bbb/ccc'. Says 'mkdir FAILED'.
<?php
$path = "/var/www/aaa/bbb/ccc";
if(!file_exists($path)) {
echo "Path does not exist, creating [".$path."]...";
if(mkdir($path, 0777, true)) {
echo "mkdir PASSED...";
}
else {
echo "mkdir FAILED...";
}
}
else {
echo "Path does exist[".$path."]...";
}
?>
This is ls -ltrh output for the php code:
-rw-r--r-- 1 root root 366 Jun 10 07:14 mdtest.php
How can I create the directory 'ccc'? Any pointers would be appreciated.
So the problem is that your apache web server has not write permission to /var/www/aaa/bbb. I dont know BSD, in debian is Apache running under www-data user. So you have to change owner of /var/www/aaa/bbb to apache user.
Run chown -hR apache /var/www
You may set all to write permission: chmod a+rw /var/www/aaa/bbb
It is a Drupal site, where includes/module.inc runs a loop over files in the registry and attempts require_once(). For a number of files this is failing, even though the file permissions are correct and the file should be readable.
I've added debug code to the loop to output to check file perms and contents:
// Debug code
print "$file perms:" . substr(sprintf('%o', fileperms($file)), -4) . "<br>";
print "$file contents:<br>" . htmlspecialchars(file_get_contents($file)) . "<hr>";
// Original Code
require_once $file;
It outputs the file permissions as well as well as the file contents before attempting the require_once. Different pages are failing on different files, the homepage for instance is outputting:
./sites/default/modules/cck/includes/content.token.inc perms:0755
./sites/default/modules/cck/includes/content.token.inc contents:
[filecontent]
./sites/default/modules/filefield/filefield.token.inc perms:0644
./sites/default/modules/filefield/filefield.token.inc contents:
[filecontent]
./sites/default/modules/getid3/getid3.install perms:0644
./sites/default/modules/getid3/getid3.install contents:
[NO FILE CONTENT]
So for some reason ./sites/default/modules/getid3/getid3.install allegedly has the permission to be readable, but isn’t.
Different paths show different files as being problematic:
/
./sites/default/modules/getid3/getid3.install perms:0644
/admin
./sites/default/modules/webform/components/date.inc perms:0644
/user
./sites/default/modules/cck/includes/content.crud.inc perms:0755
EDIT:
Note above that ./sites/default/modules/cck/includes/content.token.inc is readable but ./sites/default/modules/cck/includes/content.crud.inc gives error, here's the directory listing for those files (including --context to check for SELinux)
# ll --context
total 168
drwxr-xr-x 4 root root ? 4096 Sep 28 05:50 ./
drwxr-xr-x 8 root root ? 4096 Nov 6 2013 ../
-rwxr-xr-x 1 root root ? 72264 Nov 6 2013 content.admin.inc*
-rwxr-xr-x 1 root root ? 26307 Sep 28 03:13 content.crud.inc*
-rwxr-xr-x 1 root root ? 7181 Nov 6 2013 content.devel.inc*
-rwxr-xr-x 1 root root ? 3868 Nov 6 2013 content.diff.inc*
-rwxr-xr-x 1 root root ? 15914 Nov 6 2013 content.node_form.inc*
-rwxr-xr-x 1 root root ? 12550 Nov 6 2013 content.rules.inc*
-rwxr-xr-x 1 root root ? 6246 Nov 6 2013 content.token.inc*
drwxr-xr-x 3 root root ? 4096 Nov 6 2013 panels/
drwxr-xr-x 3 root root ? 4096 Nov 6 2013 views/
The modified date of crud is me commenting the code for testing after the errors occurred, but it is back to as it was now.
EDIT 2:
It seems that trying to access robots.txt directly is also forbidden. Not sure if this is the same problem, but again the file looks like it should be perfectly readable.
# ll robots.txt
-rw-r--r-- 1 6226 6226 1521 Aug 6 18:07 robots.txt
EDIT 3:
Looks like the problem was AppArmor, which I suppose is similar to SELinux. Changing from aa-enforce to aa-complain resolved the issue.
Perhaps some selinux cmd like might get this running :
semanage fcontext -a -t httpd_httpd_sys_content_t '/var/lib/myapp(/.*)?'
restorecon -R -v /var/lib/myapp
Where /var/lib/myapp is your ./ directory
Looks like the problem was AppArmor, which I suppose is similar to SELinux. Changing from aa-enforce to aa-complain resolved the issue.
I have really simplified it do to: mkdir(sys_get_temp_dir().'/test', 0777); which returns error
Warning: mkdir() [function.mkdir]: Permission denied in
Not sure what has happened (had quite a few problems recently with my Mac) although it appears as though it is a simple permissions problem somewhere.
sys_get_temp_dir() = /var/folders/aP/aPaKHnXDGqG-75bSdcDjkk+++TI/-Tmp-
sh-3.2# ls -ld /var/folders/
drwxr-xr-x 4 root wheel 136 12 Jul 00:51 /var/folders/
sh-3.2# ls -ld /var/folders/aP/
drwxr-xr-x 3 root wheel 102 12 Jul 00:40 /var/folders/aP/
sh-3.2# ls -ld /var/folders/aP/aPaKHnXDGqG-75bSdcDjkk+++TI/
drwxr-xr-x 4 myuser staff 136 12 Jul 00:44 /var/folders/aP/aPaKHnXDGqG-75bSdcDjkk+++TI/
Using Snow Leopard 10.6.8
MAMP Pro with Memcache extension.
Open up your terminal on your mac and type in:
chmod -R 777 /path/to/directory
Warning: Although this removes all restrictions to write/read access on such directory, 777 is a very open and insecure mode.
currently I am trying to set up a virtual machine for development for a client. Three SVN repositories with PHP code have to be combined in one folder (I know it's ugly, but that's how they roll). I Googled a little and found mhddfs. So I checked out the three repositories in a folder called branches:
branches/branch1
branches/branch2
branches/branch3
I mounted the three branches with mhddfs at /mnt/dev. At the filesystem level, everything works as expected, so ls correctly displays the contents of all three folders (they are disjoint). However, trying to fire up the document root with Apache results in a 403 Forbidden error. I tried other locations than /mnt/dev as well, leading to no difference.
[Mon Feb 06 17:44:41 2012] [error] [client 192.168.56.1]
(13)Permission denied: access to / denied
When I do not mount the three folders but just put an index.php file into /mnt/dev, everything works as expected. Am I missing something?
Thanks for your help in advance.
EDIT: Some more data on the problem: When I create two directories, that are world-accessible ...
root#devbox:/tmp > ls -lha
drwxrwxrwt 6 root root 4,0K 6. Feb 20:11 .
drwxr-xr-x 21 root root 4,0K 6. Feb 10:07 ..
drwxrwxrwx 2 www-data vboxsf 4,0K 6. Feb 20:11 test1 # includes index.htm
drwxrwxrwx 2 www-data vboxsf 4,0K 6. Feb 20:13 test2 # includes index2.htm
... and mount them via mhddfs ...
mhddfs /tmp/test1,/tmp/test2 /mnt/dev
mhddfs: directory '/tmp/test1' added to list
mhddfs: directory '/tmp/test2' added to list
mhddfs: mount to: /mnt/dev
mhddfs: move size limit 4294967296 bytes
... ls behaves correctly ...
root#devbox:/tmp > ls -lh /mnt/dev/
insgesamt 8,0K
-rwxrwxrwx 1 www-data vboxsf 12 6. Feb 20:11 index2.htm
-rwxrwxrwx 1 www-data vboxsf 11 6. Feb 20:11 index.htm
... while Apache (user: www-data, group: vboxsf) doesn't and terminates with the 403 error stated above. However, if I unmount the folders and just put an index.htm in /mnt/dev, everything works as expected as Apache can read the file.
Any ideas?
All the best,
Martin
I encountered the same problem on Linux.
Following the steps below, I was able to solve it.
[STEPS]
Enable 'user_allow_other' in /etc/fuse.conf
Use mhddfs with '-o allow_other' option ex. mhddfs -o allow_other
/dir1,/dir2 /path/to/mount