Bug 51560 - apr_stat for APR_FINFO_NORM using GetEffectiveRightsFromAcl does not work in complex Active Directory forest
Summary: apr_stat for APR_FINFO_NORM using GetEffectiveRightsFromAcl does not work in ...
Status: NEW
Alias: None
Product: APR
Classification: Unclassified
Component: APR (show other bugs)
Version: HEAD
Hardware: PC All
: P2 normal with 9 votes (vote)
Target Milestone: ---
Assignee: Apache Portable Runtime bugs mailinglist
URL:
Keywords:
Depends on:
Blocks: 51020
  Show dependency tree
 
Reported: 2011-07-26 14:38 UTC by David Boyer
Modified: 2024-03-04 07:24 UTC (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Boyer 2011-07-26 14:38:03 UTC
This is related to an Apache httpd mod_fcgid bug (51020).  A call to apr_stat is returning APR_INCOMPLETE when the machine is part of a large / complex Active Directory domain.

Cause: According to Microsoft, there are issues with using GetEffectiveRightsFromAcl http://support.microsoft.com/kb/2018746

If permissions for any Active Directory users or groups, and any local groups containing Active Directory users or groups are removed, a normal response (APR_SUCCESS) is returned.
Comment 1 David Boyer 2011-08-01 14:17:00 UTC
Wanted to add that other modules may be affected.  The only one I've experienced myself is mod_xsendfile (https://github.com/nmaier/mod_xsendfile/issues/8).
Comment 2 William A. Rowe Jr. 2011-12-12 21:48:03 UTC
Fixed in mod_fcgid trunk.  Still worthy of consideration w.r.t. apr; at least
we must retry, the error result seems like nonsense.

This bug in Windows really sucks :)
Comment 3 William A. Rowe Jr. 2011-12-12 23:53:07 UTC
We should note, patches are welcome.  It's obvious MS has no plans to support
this mechanism, moving forwards.  The larger question is; do we fail-false or
fail-true indicating access denied or access allowed by default if it cannot 
be determined?
Comment 4 Steve Hay 2019-07-25 08:06:25 UTC
I would like to see the priority on this bug raised. I recently ran into the same issue and was on the brink of raising a new bug report for it when I found this existing bug (thanks, Bugzilla!).

See the dev@ thread starting here:
https://mail-archives.apache.org/mod_mbox/apr-dev/201907.mbox/%3CCADED%3DK5PcihJA%3DvTZA2n20%2BPZ30LyTgV%2BbKuRDH%3Dc7KA0GT%2BHg%40mail.gmail.com%3E

In particular, see the two C programs (test.c and testapr.c) attached here:
https://mail-archives.apache.org/mod_mbox/apr-dev/201907.mbox/%3CCADED%3DK64bBChk8%2BsyB8QtkKiZMEwg%3DSh%2Bfp1n0kDFMzvNOpmiA%40mail.gmail.com%3E

The test.c program shows stat() working every time and testapr.c shows apr_stat() failing every time on the same file on the same system. The attempts to get APR_FINFO_GPROT and APR_FINFO_WPROT both fail, leaving apr_stat() looking silly compared to the CRT stat() function.

This failure in apr_stat() is currently causing a slew of tests to fail in a mod_perl release candidate that I'm trying to prepare.

System details:
Windows 10 Pro x64
Visual C++ 2019 v16.1.1 x64
apr 1.7.0 (also tested with 1.6.5)
Comment 5 Thorsten Schöning 2019-08-01 09:49:08 UTC
I would like to mention an issue I ran into recently and while I don't think its the same one, it sounds at least related:

http://mail-archives.apache.org/mod_mbox/perl-modperl/201907.mbox/ajax/%3C1649095749.20190731190733%40am-soft.de%3E

The main difference is that in my case no Active Directory is involved, but the problem occurs with Windows-users without admin-privileges. My setup is running mod_perl within HTTPd as a Windows service and that service uses a standard user in Windows without any admin-privileges. In that context using "apr_stat" with APR_FINFO_NORM fails, while the same usage with APR_FINFO_MIN succeeds. File::stat::stat of Perl succeeds as well.

> sub finfo    { $_[0]->{finfo}||=APR::Finfo::stat($_[0]->{filename},
>                                                  APR::Const::FINFO_NORM,
>                                                  $_[0]->pool); }

vs.

> sub finfo    { $_[0]->{finfo}||=APR::Finfo::stat($_[0]->{filename},
>                                                  APR::Const::FINFO_MIN,
>                                                  $_[0]->pool); }

Using Process Monitor things look like Windows internally requests some unexpected additional authentication. The following two lines in the logs are the last ones directly associated to mod_perl, because "mandkomm.pl" belongs to something I'm testing mod_perl with.

> 18:12:09,8533141      httpd.exe       20396   QueryRemoteProtocolInformation  C:\Users\tschoening\Documents\Eclipse\Perl DocBeam\MandKomm\mandkomm.pl INVALID PARAMETER
> 18:12:09,8533617      httpd.exe       20396   QuerySecurityFile       C:\Users\tschoening\Documents\Eclipse\Perl DocBeam\MandKomm\mandkomm.pl SUCCESS Information: Owner, Group, DACL

Directly afterwards the following Windows-related internal stuff happens:

> 18:12:09,8557370      httpd.exe       20396   CreateFile      C:\Program Files\WindowsApps\Microsoft.LanguageExperiencePackde-DE_17763.14.39.0_neutral__8wekyb3d8bbwe\Windows\System32\de-DE\ntmarta.dll.mui  SUCCESS Desired Access: Generic Read, Disposition: Open, Options: , Attributes: n/a, ShareMode: Read, Delete, AllocationSize: n/a, OpenResult: Opened
> 18:12:09,8557889      httpd.exe       20396   CreateFileMapping       C:\Program Files\WindowsApps\Microsoft.LanguageExperiencePackde-DE_17763.14.39.0_neutral__8wekyb3d8bbwe\Windows\System32\de-DE\ntmarta.dll.mui  FILE LOCKED WITH ONLY READERS   SyncType: SyncTypeCreateSection, PageProtection: PAGE_EXECUTE|PAGE_NOCACHE
> 18:12:09,8558183      httpd.exe       20396   QueryStandardInformationFile    C:\Program Files\WindowsApps\Microsoft.LanguageExperiencePackde-DE_17763.14.39.0_neutral__8wekyb3d8bbwe\Windows\System32\de-DE\ntmarta.dll.mui  SUCCESS AllocationSize: 16.384, EndOfFile: 14.720, NumberOfLinks: 1, DeletePending: False, Directory: False
> 18:12:09,8558750      httpd.exe       20396   CreateFileMapping       C:\Program Files\WindowsApps\Microsoft.LanguageExperiencePackde-DE_17763.14.39.0_neutral__8wekyb3d8bbwe\Windows\System32\de-DE\ntmarta.dll.mui  SUCCESS SyncType: SyncTypeOther
> 18:12:09,8562021      httpd.exe       20396   CreateFile      C:\Program Files\Apache Software Foundation\httpd\bin\logoncli.dll      NAME NOT FOUND  Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a
> 18:12:09,8564963      httpd.exe       20396   CreateFile      C:\Windows\System32\logoncli.dll        SUCCESS Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
> 18:12:09,8565506      httpd.exe       20396   QueryBasicInformationFile       C:\Windows\System32\logoncli.dll        SUCCESS CreationTime: 15.09.2018 09:28:46, LastAccessTime: 15.09.2018 09:28:46, LastWriteTime: 15.09.2018 09:28:46, ChangeTime: 18.12.2018 14:29:50, FileAttributes: A
> 18:12:09,8565821      httpd.exe       20396   CloseFile       C:\Windows\System32\logoncli.dll        SUCCESS 
> 18:12:09,8567588      httpd.exe       20396   CreateFile      C:\Windows\System32\logoncli.dll        SUCCESS Desired Access: Read Data/List Directory, Execute/Traverse, Synchronize, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, Delete, AllocationSize: n/a, OpenResult: Opened
> 18:12:09,8568147      httpd.exe       20396   CreateFileMapping       C:\Windows\System32\logoncli.dll        FILE LOCKED WITH ONLY READERS   SyncType: SyncTypeCreateSection, PageProtection: PAGE_EXECUTE|PAGE_NOCACHE
> 18:12:09,8568718      httpd.exe       20396   CreateFileMapping       C:\Windows\System32\logoncli.dll        SUCCESS SyncType: SyncTypeOther
> 18:12:09,8570352      httpd.exe       20396   CloseFile       C:\Windows\System32\logoncli.dll        SUCCESS 
> 18:12:09,8577214      httpd.exe       20396   CreateFile      C:\Program Files\Apache Software Foundation\httpd\bin\netutils.dll      NAME NOT FOUND  Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a
> 18:12:09,8580361      httpd.exe       20396   CreateFile      C:\Windows\System32\netutils.dll        SUCCESS Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
> 18:12:09,8581042      httpd.exe       20396   QueryBasicInformationFile       C:\Windows\System32\netutils.dll        SUCCESS CreationTime: 15.09.2018 09:28:46, LastAccessTime: 15.09.2018 09:28:46, LastWriteTime: 15.09.2018 09:28:46, ChangeTime: 18.12.2018 14:29:37, FileAttributes: A
> 18:12:09,8581470      httpd.exe       20396   CloseFile       C:\Windows\System32\netutils.dll        SUCCESS 
> 18:12:09,8583470      httpd.exe       20396   CreateFile      C:\Windows\System32\netutils.dll        SUCCESS Desired Access: Read Data/List Directory, Execute/Traverse, Synchronize, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, Delete, AllocationSize: n/a, OpenResult: Opened
> 18:12:09,8584031      httpd.exe       20396   CreateFileMapping       C:\Windows\System32\netutils.dll        FILE LOCKED WITH ONLY READERS   SyncType: SyncTypeCreateSection, PageProtection: PAGE_EXECUTE|PAGE_NOCACHE
> 18:12:09,8584618      httpd.exe       20396   CreateFileMapping       C:\Windows\System32\netutils.dll        SUCCESS SyncType: SyncTypeOther
> 18:12:09,8586230      httpd.exe       20396   CloseFile       C:\Windows\System32\netutils.dll        SUCCESS 
> 18:12:09,8622225      httpd.exe       20396   CreateFile      \\VORDEFINIERT*\MAILSLOT\NET\NETLOGON   SUCCESS Desired Access: Generic Write, Read Attributes, Disposition: OpenIf, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: 0, OpenResult: Superseded
> 18:12:09,8622960      httpd.exe       20396   WriteFile       \\VORDEFINIERT*\MAILSLOT\NET\NETLOGON   BAD NETWORK PATH        Offset: 0, Length: 78, Priority: Normal
> 18:12:23,4057050      httpd.exe       20396   CloseFile       \\VORDEFINIERT*\MAILSLOT\NET\NETLOGON   SUCCESS 
> 18:12:23,4094073      httpd.exe       20396   CreateFile      \\VORDEFINIERT*\MAILSLOT\NET\NETLOGON   SUCCESS Desired Access: Generic Write, Read Attributes, Disposition: OpenIf, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: 0, OpenResult: Superseded
> 18:12:23,4095101      httpd.exe       20396   WriteFile       \\VORDEFINIERT*\MAILSLOT\NET\NETLOGON           Offset: 0, Length: 78, Priority: Normal

The NETLOGON-thing repeats until I guess a timeout of ~30 seconds happens and starting HTTPd simply fails in the end.

As APR_FINFO_NORM seems to be normal usage, I don't think higher privileges than those of a standard user should be necessary to succeed. The problem happens with HTTPd using APR 1.70. as well as with APR 1.6.5. The thread at dev@ mention changes regarding symlinks/junctions in both versions and while I do use junctions in that context, the problem occurs with and without those in both versions of APR.