Bug #68926 [Com]: is_writable returns false but file_put_contents works
| From: | alex dot goris at fastlikehell dot com | Date: | Fri, 26 Aug 2016 12:48:12 +0000 |
| Subject: | Bug #68926 [Com]: is_writable returns false but file_put_contents works | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-203572@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=68926&edit=1
ID: 68926
Comment by: alex dot goris at fastlikehell dot com
Reported by: lukyer at gmail dot com
Summary: is_writable returns false but file_put_contents
works
Status: Analyzed
Type: Bug
Package: *Directory/Filesystem functions
Operating System: Windows 8 64b Prof.
PHP Version: 5.6Git-2015-01-27 (Git)
Assigned To: ab
Block user comment: N
Private report: N
New Comment:
I believe I have this bug in my development environment.
I am running PHP 5.6.22, 64-bit version, my workstation is Windows 10 Pro x64.
I am developing in Visual Studio using the DevSense phptools plugin, this plugin debugs the code
using xdebug and the built-in webserver of php.exe
I have created the following test script:
<?php
var_dump(is_writable("//10.151.140.102/TestAlex/SubFolder1/"));
var_dump(file_put_contents("//10.151.140.102/TestAlex/SubFolder1/Test.txt",
"Testing..."));
var_dump(is_writable("//127.0.0.1/c$/temp/SubFolder1/"));
var_dump(file_put_contents("//127.0.0.1/c$/temp/SubFolder1/Test.txt",
"Testing..."));
?>
Which outputs:
script1.php:2:boolean false
script1.php:3:int 10
script1.php:4:boolean true
script1.php:5:int 10
Note that the first line returns false
However, I do have write permissions on the //10.151.140.102/TestAlex/SubFolder1/ folder.
Also, the Test.txt file exists in that directory with the 'Tersting...' string.
Note that am a member of the Administrators group on the 10.151.140.102 machine.
I was surprised to see the is_writable() function returning true on the \\127.0.0.1\c$\... share,
this I can not explain...
This is going wrong on 2 different development machines (both running above mentioned
configuration).
On our test webserver, which runs Windows 2008 R2 x64, Apache 2.4.4 and php 5.6.16 the is_writable()
function correctly sees the \\10.151.140.102\TestAlex\... path as writable and returns true
Previous Comments:
------------------------------------------------------------------------
[2015-06-05 17:34:21] ab@php.net
@webmastersguide2000,
thanks for the report.
How it looks like, your issue is different from what is originally reported here. If it is on the
local FS, it's most likely a misconfiguration. The unmapped unix users are unlikely to be in
the game, but what were imaginable for example is the ACLs difference concerning the system account
for CLI and the impersonated account used under IIS.
If you still think it's the same issue, please prove it with some stable reproduce case. Maybe
some rolle could play that those files are additionally shared through SMB. Please test also the
latest VC11 builds like PHP 5.6, the 5.4 branch only accepts the security fixes so we won't be
able to pass any corrections there, just for the case.
Thanks.
------------------------------------------------------------------------
[2015-06-04 21:28:02] webmastersguide2000 at yahoo dot com
> This issue is related to SAMBA.
The problem does occur when files are accessed locally, without SMB. (SAMBA is Linux, SMB is
Windows).
In our case, the storage is _also_ shared from the affected machine to other clients via SMB, but
the problem occurs when the files are accessed locally, not via SMB.
------------------------------------------------------------------------
[2015-06-04 21:06:42] yohgaki@php.net
This issue is related to SAMBA.
Anyone who experiences this, please add your Samba configurations.
There is similar issue reported for session storage on mounted (shared) file system. This may be the
reason why some users have session storage issue on mounted files under windows.
------------------------------------------------------------------------
[2015-06-04 19:13:28] webmastersguide2000 at yahoo dot com
I get a similar symptom going back to at least 5.4.19, but without Samba.
We are running:
PHP Version 5.4.19
System Windows NT DEV-LMS2 6.1 build 7601 (Windows Server 2008 R2 Enterprise Edition Service Pack 1)
i586
Build Date Aug 21 2013 01:06:09
Compiler MSVC9 (Visual C++ 2008)
Architecture x86
Configure Command cscript /nologo configure.js "--enable-snapshot-build"
"--enable-debug-pack" "--disable-zts" "--disable-isapi"
"--disable-nsapi" "--without-mssql" "--without-pdo-mssql"
"--without-pi3web" "--with-pdo-oci=C:\php-sdk\oracle\instantclient10\sdk,shared"
"--with-oci8=C:\php-sdk\oracle\instantclient10\sdk,shared"
"--with-oci8-11g=C:\php-sdk\oracle\instantclient11\sdk,shared"
"--with-enchant=shared" "--enable-object-out-dir=../obj/"
"--enable-com-dotnet=shared" "--with-mcrypt=static"
"--disable-static-analyze" "--with-pgo"
In my case at least, is_writeable also returns false for directories which are writeable.
------------------------------------------------------------------------
[2015-02-12 19:00:59] ab@php.net
I've spent some time on debugging this and can confirm. The reason for this behavior is here https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/ChangeNotes.html#id2578661
.
You probably could check that
- you use samba3 or above
- the folder owner is mapped to something like "nobody", with either full or restricted
access rights (use right click -> security -> advanced)
You also could play with the access rights on the linux machine, just to see whether it changes
something in PHP behavior.
The issue here is that unmapped unix user accounts are mapped to built-in windows SIDs, which are
obviously have nothing to do with windows ACLs. We could currently look whether it's possible
to cover this part within PHP. In general it looks more like samba compat issue, because as
you've mentioned - the native shares work well.
Regards
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=68926
--
Edit this bug report at https://bugs.php.net/bug.php?id=68926&edit=1