php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #26224 fileperms() inaccurately reports permissions
Submitted: 2003-11-12 13:04 UTC Modified: 2017-10-24 01:49 UTC
Votes:5
Avg. Score:4.2 ± 0.7
Reproduced:2 of 2 (100.0%)
Same Version:0 (0.0%)
Same OS:1 (50.0%)
From: justin dot white at mci dot com Assigned: kalle (profile)
Status: Closed Package: Filesystem function related
PHP Version: 4.3.3 OS: Windows 2000
Private report: No CVE-ID: None
View Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
28 + 50 = ?
Subscribe to this entry?

 
 [2003-11-12 13:04 UTC] justin dot white at mci dot com 
Description:
------------
On Linux, PHP 4.3.3 correctly returns file permissions from the filesystem.  With Windows 2000 and IIS, PHP in CGI or ISAPI mode does not.  The reproduce code assumes that another file (TEST.PHP) already exists in the filesystem.  Any other file or directory could be used (although the permissions are returned differently for directories).  TEST.PHP can have any permissions, including explicitly DENY "Full Access" for EVERYONE group.

Reproduce code:
---------------
<?php
  clearstatcache();
  $test = fileperms('c:/inetpub/wwwroot/test.php');
  echo '<H1>PERMS = ';
  $read = ($test & 0x0004) ? 'r' : '-';
  $write = ($test & 0x0002) ? 'w' : '-';
  $execute = ($test & 0x0001) ? 'x' : '-';
  echo $read.$write.$execute.'</H1>';
?>

Expected result:
----------------
For files, returned results should be "<H1>PERMS = r--</H1>' if permissions were set to READ.  Returned results should be "<H1>PERMS = rw-</H1>" if permissions were set to READ/WRITE or READ/WRITE/MODIFY.  Returned results should be "<H1>PERMS = rwx</H1>" if permissions were set to READ/EXECUTE/WRITE or READ/EXECUTE/WRITE/MODIFY or FULL CONTROL.

For directories, returned result should be similar (although permissions on directory are more well-defined).

Actual result:
--------------
For files, returned results will always be "<H1>PERMS = rw-</H1>';

For directories, returned result will always be "<H1>PERMS = rwx</H1>';

Even attempting this operation on "C:/pagefile.sys" returned "<H1>PERMS = rw-".

Curiously, when marking the file as "read-only" in the file properties (not security tab), the returned results are "<H1>PERMS = r--</H1>" for files and "<H1>PERMS = r-x</H1>" for directories.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-11-12 13:06 UTC] justin dot white at mci dot com 
The server in the test setup uses NTFS in all filesystems.
 [2003-11-12 13:08 UTC] iliaa@php.net 
Does it work if you use the is_readable/is_writeable/is_executable functions instead of performing bitmask operations on the output of fileperms() ?
 [2003-11-12 13:23 UTC] justin dot white at mci dot com 
No, the result is the same.  It appears that fileperms() and is_readable/is_writeable are all reading their permissions from file properties and not from filesystem permissions.

Also, is_executable returned the following error:

"Fatal error: Call to undefined function: is_executable()".

I didn't see where a note was given about availability in Win32 train, so I don't what is up with that.  Both is_readable() and is_writeable() were available, although incorrect.
 [2003-11-12 13:24 UTC] justin dot white at mci dot com 
I also have a RH8 server with PHP 4.3.3 available and the sample code works flawlessly.
 [2003-11-12 23:56 UTC] justin dot white at mci dot com 
I have been able to confirm that version 4.3.2 does not have this bug.  I will be testing 4.3.4 shortly to see whether the bug has been resolved...
 [2003-11-13 04:14 UTC] justin dot white at mci dot com 
Oops.  It looks like my statement about 4.3.2 was incorrect.  The system I was looking at had some files labeled as "Read Only" in the file properties, but the file security had no bearing on the result...

Back to the drawing board.
 [2003-11-13 08:19 UTC] wez@php.net 
You do realize that DOS only has a notion of a limited
set of file attributes? (essentially, there is just a
read-only flag).

The "security tab" under windows displays the contents
of the NTFS ACL; PHP just uses the functions provided
by the MS libc, which seem to ignore the ACL.
 [2003-11-13 11:17 UTC] justin dot white at mci dot com 
I think if you had read my post that you would have known that I understood what attributes DOS offered.  However, we're not talking about DOS here.

In Windows NT/2000/XP/2003, NTFS ACLs are completely ignored by PHP in determining the file properties.  If libc does not provide a list of NTFS permissions, the list should be available through other means.  That's a pretty important function for filesystem access.

The only way to fix the problem is a change specifically for Win32 to use the GetSecurityInfo() call from Win32 API.  Here's some information on it from MSDN:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/security/getsecurityinfo.asp

Apparently, the Tcl-win folks have had the same problem in porting Tcl to Windows.  Here's a discussion of their problems and possible solutions:

https://sourceforge.net/tracker/?func=detail&atid=110894&aid=749876&group_id=10894
 [2016-12-30 18:53 UTC] cmb@php.net
-Package: Feature/Change Request +Package: Filesystem function related
 [2017-10-24 01:49 UTC] kalle@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: kalle
 [2017-10-24 01:49 UTC] kalle@php.net 
I'm pretty sure this was fixed in the movement of providing a more solid Windows implementation for PHP that began in PHP 5.3, closing this report.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Sun Oct 26 09:00:01 2025 UTC