[W2K/PHP] Rechten op uploadtmp worden hersteld naar default

[EBOOZ]

Om ons intranet te verzorgen is door één van mijn voorgangers een Windows 2000 Server (SP4) ingericht met IIS in combinatie met PHP versie 4.4.4.

Per 1 november a.s. willen we een nieuw intranet in gebruik gaan nemen, geheel met CMS, uploadfuncties, e.d. Echter kampen we op het moment met een probleem met de uploadtmp map die is ingesteld in php.ini.

De map uploadtmp stond in eerste instantie in C:\PHP en had de volgende rechten:
Administrators - Full
SYSTEM - Full
Web Anonymous Users: Read, Execute, Write, Modify
Inheritable permissions - Uit

Als we vervolgens gingen testen, ging het uploaden goed en werden er ook .tmp bestanden toegevoegd in de uploadtmp-map.
Enkele uren later was het uploaden echter niet meer mogelijk. Bij het checken van de rechten op de map zag ik dat deze weer op de defaults waren teruggezet. Dat wil zeggen; Web Anonymous Users was verwijderd, Everyone was toegevoegd met leesrechten en Inheritable permissions stond weer aan.
Na verschillende malen de rechten weer te hebben aangepast en diverse variaties qua rechten te hebben bedacht, moest ik elke keer weer constateren dat de rechten weer terug werden gezet naar defaults.

Hierna heb ik een nieuwe uploadtmp map gemaakt in C:\Inetpub en in php.ini aangegeven dat deze map gebruikt moet worden voor de tijdelijke bestanden. Wederom de rechten goed gezet en getest. Alles werkte naar behoren.
Maar ook na het gebruiken van de uploadtmp map in Inetpub gebeurde het nog steeds dat de rechten na een aantal uur werden teruggezet, waardoor het uploaden niet meer mogelijk was.
De aanpassingen van rechten op andere mappen die in C:\Inetpub staan, blijven wel gehandhaafd. Het betreft echt alleen de map uploadtmp die met die probleem te maken heeft.

Zoeken op Google en PHP.net bood geen oplossing. Onderhand heb ik denk ik een beetje een tunnelvisie opgebouwd denk ik, vandaar dat ik even een frisse kijk op dit probleem nodig heb

Thanks!

[Verwijderd]

Volgens mij heeft je voorganger een cron-job achtig ding aangemaakt die er voor zorgt dat je temp-dir automagisch wordt opgeschoond. Hierbij laat hij gewoon je c:/php directory overschrijven door een standaarddir die hij ergens heeft opgeslagen.

[EBOOZ]

Hoe verklaar je dan dat hetzelfde probleem optreed op C:\Inetpub\uploadtmp?

[_js_]

Process Monitor van Microsoft downloaden.
Filter voor Path instellen op je upload map en Operation op SetSecurityFile.
Wachten.
Kijken welk programma dit gedaan heeft.

[sanfranjake]

Heb je misschien Active Directory draaien met een group policy welke er voor zorgt dat de rechten overschreven worden?

[EBOOZ]

Nee er wordt geen group policy toegepast.

Het is ook zo vreemd dat echt de complete "uploadtemp" map hersteld wordt qua rechten. Als ik bijvoorbeeld een map in dezelfde directory als uploadtemp zet, blijven de rechten wel gewoon staan.

Ik ben nu bezig om dat Process Monitor te installeren op de server, maar daar heb ik Update Rollup 1 voor nodig en die kan ik niet zomaar in de productie omgeving gaan installeren, aangezien er aardig wat haken en ogen aan zitten (Update Rollup 1 for Windows 2000 SP4 and known issues)

[sanfranjake]

Kijk ook eens in de taakplanner (als je dat nog niet had gedaan), er zijn best een berg commandline tools die dit kunnen aanpassen. Anders zou je misschien een temp-fix kunnen maken met cacls (acl om de 10 min resetten ofzo)

Als het allemaal mogelijk is zou ik die hele map inetpub of uploadtemp eens oppakken en elders huizen. Gebeurt het dan nog?

[EBOOZ]

Ik zal morgen even kijken.

In de taakplanner stond in ieder geval niets en naar die temp-fix zal ik even kijken.

Maar goed in ieder geval dat ik het hier even heb gepost, want ik ging er onderhand blind vanuit dat het aan PHP lag

[sanfranjake]

EbOoZ schreef op donderdag 18 oktober 2007 @ 19:05:
Maar goed in ieder geval dat ik het hier even heb gepost, want ik ging er onderhand blind vanuit dat het aan PHP lag

Sluit nooit iets uit voordat je het uitvoerig hebt bestudeerd. Aannames zijn nogal fataal, zeker met computer-meuk

[EBOOZ]

Ja heb je helemaal gelijk in, maar soms heb je gewoon last van zo'n tunnel-visie. En dan komt GoT toch altijd weer mooi van pas

[sanfranjake]

En is het al opgelost? Ik ben eigenlijk wel nieuwsgierig wat het nou was

[EBOOZ]

Procesmonitor draait, moet het alleen zelf nog even gaan monitoren

Was van de week druk met een project opleveren, maar ik kom hier op terug!

[DVRIES]

Hoi,

Ik ben een nieuwe collega van Ebooz en ben ook een beetje in het probleem gedoken. Helaas nog niet veel verder gekomen behalve dat we nu eindelijk een resultaat hebben dankzij de proces monitor tool wat/wie de rechten terug zetten

Hier vind je de log file die gegenereert is door de proces monitor tool:

code:

************************************
**             EVENT              **
************************************
Sequence:   336077
Date & Time:    15-11-2007 11:57:11
Event Class:    File System
Operation:  SetSecurityFile
Result: SUCCESS
Path:   C:\Inetpub\uploadtmp
TID:    372
Duration:   0.0000551
Information:    DACL


************************************
**            PROCESS             **
************************************
Description:    Services and Controller app
Company:    Microsoft Corporation
Name:   services.exe
Version:    5.00.2195.7035
Path:   C:\WINNT\system32\services.exe
Command Line:   C:\WINNT\system32\services.exe
PID:    288
Parent PID: 236
Session ID: 0
User:   NT AUTHORITY\SYSTEM
Auth ID:    00000000:000003e7
Architecture:   32-bit
Virtualized:    n/a
Integrity:  n/a
Started:    14-11-2007 16:18:06
Ended:  (Running)
Modules:


************************************
**             STACK              **
************************************
0   fltmgr.sys  fltmgr.sys + 0x941  0xbff4e941  C:\WINNT\System32\Drivers\fltmgr.sys
1   fltmgr.sys  fltmgr.sys + 0x4162 0xbff52162  C:\WINNT\System32\Drivers\fltmgr.sys
2   fltmgr.sys  fltmgr.sys + 0x47d1 0xbff527d1  C:\WINNT\System32\Drivers\fltmgr.sys
3   ntoskrnl.exe    ntoskrnl.exe + 0x1eec9  0x8041eec9  C:\WINNT\System32\ntoskrnl.exe
4   ntoskrnl.exe    ntoskrnl.exe + 0x51d15  0x80451d15  C:\WINNT\System32\ntoskrnl.exe
5   ntoskrnl.exe    ntoskrnl.exe + 0x68309  0x80468309  C:\WINNT\System32\ntoskrnl.exe
6   PROCMON11.SYS   PROCMON11.SYS + 0x709   0xf66f8709  C:\WINNT\system32\Drivers\PROCMON11.SYS
7   PROCMON11.SYS   PROCMON11.SYS + 0xa18   0xf66f8a18  C:\WINNT\system32\Drivers\PROCMON11.SYS
8   PROCMON11.SYS   PROCMON11.SYS + 0x27df  0xf66fa7df  C:\WINNT\system32\Drivers\PROCMON11.SYS
9   fltmgr.sys  fltmgr.sys + 0x941  0xbff4e941  C:\WINNT\System32\Drivers\fltmgr.sys
10  fltmgr.sys  fltmgr.sys + 0x4162 0xbff52162  C:\WINNT\System32\Drivers\fltmgr.sys
11  fltmgr.sys  fltmgr.sys + 0x47d1 0xbff527d1  C:\WINNT\System32\Drivers\fltmgr.sys
12  ntoskrnl.exe    ntoskrnl.exe + 0x1eec9  0x8041eec9  C:\WINNT\System32\ntoskrnl.exe
13  ntoskrnl.exe    ntoskrnl.exe + 0x51d15  0x80451d15  C:\WINNT\System32\ntoskrnl.exe
14  ntoskrnl.exe    ntoskrnl.exe + 0x68309  0x80468309  C:\WINNT\System32\ntoskrnl.exe

Het lijkt er dus op dat services.exe de opratie setsecurityfile aanroept en vervolgens met succes de rechten terug zet.

Enig idee hoe dit mogelijk is?

[sanfranjake]

100% zeker dat er nergens een policy of script om de X tijd draait wat dit veroorzaakt?
Blijft dit gebeuren als je alle niet-Microsoft services stopt?
Of de map elders ook aangewezen in de applicatie? Waar deze expliciet read-only moet zijn?

100% zeker ook dat er toch niet iets in de applicatie zit? Zit er een patroon in? Exact hoe vaak gebeurt dit? En wat gebeurt er op die momenten allemaal op de server?

Welke virusscanner gebruik je? Sommige virusscanners hebben ook dit soort features (ik denk dan aan een wildcard op tmp ofzo in een regel die mappen voor bepaalde processen read only maakt of een predefined rechtentemplate toepast ofzo.

Allemaal maar gegis, ik hoop dat je er wat aan hebt

[DVRIES]

Er draait geen policy/script op de server. We kunnen ook niet te gek veel dingen gaan testen behalve op de uren dat de gebruikers niet aanwezig zijn.

We gebruiken McAfee virusscanner en we hebben hier even naar gekeken maar niets kunnen ontdekken.

Het is wel duidelijk dat de rechten na een herstart van de server op de map blijven bestaan. Dit is dus erg vreemd en maakt het nog moeilijker om de oorzaak te ontdekken.

Er is niet echt een patroon waar te nemen, het verschilt per keer dat de rechten verdwijnen.. soms een paar uur, soms een dag. Heel mysterieus allemaal.

We hebben de procesmonitor nog even laten draaien maar als deze te lang aan staat loopt het geheugen van de server vol en dient hij te worden herstart.

We blijven puzzelen/zoeken. In ieder geval bedankt voor het meedenken en mocht je nog iets te binnen schieten dan horen we dat graag