2

A bit of a long shot here but thought I'd see if anyone had a fix for this:

I am having an issue whereby the PHP function unlink() is being able to successfully delete a file even though explicit deny NTFS permissions have been applied to the file in question. I have even tried removing all NTFS file permissions and the like - same outcome and it has me stumped.

FACTS

  • I have Apache 2.2.22 running PHP 5.4.5 on Windows Server 2008 R2

  • Apache/PHP are running under user EXODUS\wwwuser, proven by response to 'whoami' at command line from running PHP script - eg:

    echo exec('whoami');

    returns EXODUS\wwwuser

  • The file 'deleteme.txt' is created by a member of the 'BUILTIN\Administrators' group, explicity deny permissions are applied to the file for EXODUS\wwwuser - however, PHP's unlink() function successfully deletes the file.

  • I have tried this same thing by removing permission inheritance on this file, removing all permissions (including SYSTEM), and applying explicit deny 'FULL CONTROL' to EXODUS\wwwuser - guess what, unlink() still deletes the file...

  • EXODUS\wwwuser is a member of BUILTIN\Users, however this doesn't indicate that this would impact the situation.

  • File cannot be deleted by EXODUS\wwwuser when logged in interactively.

  • When files are written by PHP, file owner is 'EXODUS\wwwuser'

Does anyone have any thoughts on this?

How would I go about providing folders/files that cannot be deleted in a location via PHP's unlink() that are inside a defined 'open_basedir' area?

I'm using 'open_basedir' to stop scripts tampering with files outside of the declared open_basedir - this seems to be working fine - eg: can't delete files that are outside the location defined by 'open_basedir'.

7
  • What does the "Effective permissions" dialog say when you select your user ? (right click file/properties/security/advanced).
    – Tibo
    Aug 8, 2012 at 8:02
  • Hi @Tibo, 'Effective permissions' tab, after choosing user 'EXODUS\wwwuser' shows no permission boxes ticked. Aug 8, 2012 at 8:08
  • Weird ... I guess this is an OS issue, not really related to PHP itself. The help page "how effective permissions are determined" provides a few pointers (exceptions to the rules), and maybe Technet has some too.
    – Tibo
    Aug 8, 2012 at 8:17
  • One important gotcha here (although I'm not sure it applies given the facts above) is that if you change security group memberships, the implied alteration of permissions does not take effect until the user logs off and logs on again. When running a service as a user that is also allowed to log on interactively, I'm not sure how this works - it may be that restarting the service will effect the permissions changes, and it may be that you'd need to reboot the whole system. One thing I'm fairly certain of though is that an interactive log off/on will not affect the service's behaviour.
    – DaveRandom
    Aug 8, 2012 at 8:30
  • @DaveRandom - Just to be sure I removed the 'Logon as a service' right from wwwuser (eg: Admin Tools > Local Security Policy > Removed 'EXODUS\wwwuser' from 'Log on as a service'). Note that in the testing above I am yet to actually run httpd.exe (apache +php via mod_php) as a Service - it has all happened interactively. See link for screenshot showing another test where I removed all file permissions from the file - I can confirm I cannot delete this file as EXODUS\wwwuser or EXODUS\Administrator link Aug 8, 2012 at 9:10

3 Answers 3

1

Hi if PHP is able to delete a file even though the permissions say otherwise. This probably means that the Apache is running as user with Administrator privs.

You can always try to audit the folder in windows to make sure all the child folders permissions are reset if the above isn't the problem.

0

I don't use PHP on Windows, so can't be sure of it's underlying code but when I write any form of delete function the first thing I have it do is to try and remove existing permissions. Just maybe unlink() is doing the same. If you have appropriate logging enabled you should be able to see any such behaviour in the Windows event logs, so check in there.

2
  • 1
    Check this one out - bugs.php.net/bug.php?id=10345 - Seems to indicate that it's a feature... "This is not a bug but how the filesystem works. Permissions for erasing a file is according to the permissions on the directory and not the file." - I would have thought that even if the file in a containing directory has permission inheritance disabled and explicit deny permissions on delete for the file in question, for the user attempting to unlink/delete the file that it would fail... Aug 11, 2012 at 11:51
  • @James, even after all these years I didn't know that, perhaps because it's never had a situation where that applied. I've learned something today and I'm still having breakfast. Aug 11, 2012 at 23:32
0

The only way this is possible is if the Apache server is not actually running under the user you say it is. Turn on auditing on that folder and test again to see what user is deleting the file.

Also, who is the owner of the file?

1
  • Owner of the file is EXODUS\Administrators (group). EXODUS\wwwuser is not part of the Administrators group. I'm going to setup auditing to see what is actually happening and get back to you. Aug 11, 2012 at 11:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .