php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #73543 Network drive file: is_readable() == false but file can be read
Submitted: 2016-11-16 14:42 UTC Modified: 2022-02-12 02:27 UTC
Votes:5
Avg. Score:5.0 ± 0.0
Reproduced:3 of 3 (100.0%)
Same Version:2 (66.7%)
Same OS:3 (100.0%)
From: hsh at autowise dot dk Assigned:
Status: Open Package: Filesystem function related
PHP Version: 7.0.13 OS: Windows 10
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: hsh at autowise dot dk
New email:
PHP Version: OS:

Further comment on this bug is unnecessary.

 

 [2016-11-16 14:42 UTC] hsh at autowise dot dk
Description:
------------
The is_readable() functions seems to interpret network drive ACLs incorrectly such that readable files are interpreted as unreadable.

This problem seems to be related to the bug: #53214 but in my case the bug reveals itself on a real Samba server running Samba v4.3.11, and not via VirtualBox. The Samba server is running as domain controller using extended ACLs and the:
  idmap_ldb:use rfc2307 = yes
flag is enabled in smb4.conf

Test script:
---------------
Samba share: S:\

S:\> echo "Hello World" > test.txt

S:\> php -r "echo is_readable('test.txt')?'true':'false';"
false

S:> php -r "echo file_get_contents('test.txt');"
"Hello World"


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2016-11-16 14:52 UTC] cmb@php.net
That looks like a duplicate of bug #69834.
 [2016-11-16 14:59 UTC] hsh at autowise dot dk
Yes, except that I'm not using the Windows Offline Files feature. It could easily be a manifestation of the same bug though if both bugs are Windows ACL-related.
 [2016-11-21 11:38 UTC] ab@php.net
Thanks for the report. I was hunting this bug earlier, however it didn't come to a distinct solution. It still looks to me, this ticket is a duplicate of bug #68926, so still either Samba or a config issue. Probably hard to say, without having some debug session, and creating a reproduce environment is probably the most tricky part. 

Thanks.
 [2016-11-22 15:40 UTC] hsh at autowise dot dk
I'm putting my money on this being the same underlying bug as #68926, and the line from the bug report:

>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. 

...is in effect in my setup as well and I think it's the core of the problem: I have not joined the AD, but provided my credentials only when connecting the drive.

The code which compares access rights to SIDs cannot get several of the SIDs resolved on a host which is not an AD member - and never will.

A couple if years ago when I was programming an IIS/C#/ASP intranet application and was faced with the same problem of showing only files readable by the logged in user (or rather the IIS impersonated one) and needed an is_readable() equivalent in C#. I ditched calling all the built in ACL check functions and just opened the file for reading without doing anything. eg, the PHP equivalent of:

function is_readable(string $file_in): bool
{
   try {
     if(is_resource($handle=fopen($file_in, "r")))
     {
        fclose($handle);
        return true;
     }
     return false;
   }
   catch(Exception $ex)
   {
      return false;
   }
}

I predicted the worst performance wise and expected the logs being full of rejected read attempts, but the code was snappy even with thousands of files in the remote directory and nothing was logged. A simple solution to a tricky problem I guess, but I have no idea if this could be the solution to this bug too. My C/C++ is far too rusty...
 [2022-02-12 02:27 UTC] requinix@php.net
-Block user comment: No +Block user comment: Yes
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Nov 24 16:01:31 2024 UTC