تغييرات GetTempPath في معاينة التحديث التراكمي ل Windows فبراير

الملخص

قامت Microsoft بطرح تحسينات الأمان على الإصدارات الأخيرة من Windows. تعمل تحسينات الأمان هذه على تعديل معالجة المسار المؤقت وقد تتسبب في إرجاع بعض واجهات برمجة تطبيقات .NET Framework و.NET مثلSystem.IO.Path.GetTempPath()إلى موقع مختلف بعد تطبيق التصحيح.

الإجراء المطلوب

لا يلزم اتخاذ أي إجراء من أي .NET Framework أو . التطبيق المستند إلى NET. سيستفيد تطبيقك تلقائيا من أي تحسينات أمنية تنطبق على بيئتك. لن تلاحظ معظم التطبيقات أي تغيير سلوكي.

يوضح الجزء المتبقي من هذه المقالة كيفية تحديد ما إذا كانت تحسينات الأمان هذه قد تؤثر على سلوك وقت التشغيل للتطبيق الخاص بك. تسرد هذه المقالة أيضا خطوات تخصيص سلوك وقت التشغيل إذا رغبت في ذلك

البرامج القابلة للتطبيق

تنطبق هذه المقالة على البرنامج التالي:

.NET 8 وأعلى
.NET Framework، جميع الإصدارات، اعتبارا من تحديثات الأمان في يوليو 2024 والتحديثات اللاحقة

فقط عند التشغيل على إصدارات تحديث Windows التالية:

Windows 10، الإصدار 22H2 عند تثبيت KB5052077
Windows Server 2019، عند تثبيت KB5053594
Windows Server 2016، عند تثبيت KB5053594

لا تنطبق هذه المقالة على .NET Framework أو .NET قيد التشغيل على Windows 11 أو Windows Server 2022 أو أحدث.

لا تنطبق هذه المقالة على .NET عند التشغيل على أنظمة أساسية غير Windows.

وصف مفصل وبيان التأثير

اعتبارا من KBs لتحديث Windows المذكور أعلاه، قامت Microsoft بإعادة تشغيل واجهة برمجة تطبيقات Win32 GetTempPath2 إلى الإصدارات القديمة في السوق من Windows للعمل كبديل أكثر أمانا لواجهة برمجة تطبيقات Win32 GetTempPath القديمة. داخليا، تعتمد .NET Framework و.NET على واجهات برمجة التطبيقات Win32 هذه لتوفير تنفيذ أسلوب System.IO.Path.GetTempPath() : يفضل Win32 GetTempPath2 API إذا كانت موجودة؛ ويتم استخدام واجهة برمجة تطبيقات Win32 GetTempPath كطريقة احتياطية إذا لم يكن GetTempPath2 موجودا.

نظرا لأن KBs هذه تجعل واجهة برمجة تطبيقات Win32 GetTempPath2 الجديدة متاحة على الأنظمة الأساسية القابلة للتطبيق، سيبدأ .NET Framework و.NET في استخدام GetTempPath2 بمجرد تثبيت KBs.

التغيير السلوكي الأساسي هو أن المتصلين الذين يعملون كهوية SYSTEM سيراقبون %WINDIR%\SystemTemp الأسلوب System.IO.Path.GetTempPath() بشكل افتراضي، في حين أن المتصلين الذين يعملون كأي شيء آخر غير هوية SYSTEM سيلاحظون أن الأسلوب سيستمر في إرجاع قيمته الحالية.

إذا كان التطبيق الخاص بك يفي بجميع المعايير أدناه، فقد تتأثر بهذا التغيير:

يستخدم التطبيق الخاص بك وقت التشغيل والنظام الأساسي لنظام التشغيل المدرج تحت عنوان "البرامج القابلة للتطبيق" السابق؛ و
يعمل التطبيق الخاص بك كهوية SYSTEM؛ و
يمكنك تعيين متغير البيئة %TMP% أو %TEMP% يدويا لإعادة توجيه موقع الملف المؤقت القياسي. (راجع قسم الملاحظات في وثائق Win32 GetTempPath API.)

إذا كنت تفي بجميع هذه المعايير، فبمجرد تثبيت Windows KBs، يمكنك مراقبة كتابة التطبيق الخاص بك إلى دليل مؤقت غير الدليل الذي قصدته.

قد يكون هذا التغيير السلوكي مرئيا من خلال أي .NET Framework أو . واجهة برمجة التطبيقات التي توفرها NET والتي تعتمد في النهاية على GetTempPath2. نقاط الدخول الأكثر شيوعا هي:

لا يقصد بهذا أن يكون قائمة شاملة بالأساليب التي قد تتغير سلوكياتها بمجرد تثبيت KBs.

تحديد ما إذا كان التطبيق يعمل ضمن هوية SYSTEM

هناك العديد من الآليات المختلفة لتحديد هوية تطبيق .NET Framework أو .NET

تطبيقات الويب المستندة إلى IIS

يشير IIS إلى هوية SYSTEM باسم "LOCALSYSTEM". في إدارة IIS (inetmgr.exe)، انتقل إلى علامة التبويب تجمعات التطبيقات لمشاهدة جميع تجمعات التطبيقات والهويات المرتبطة بها. يمكنك أيضا تحديد "الهوية" من القائمة المنسدلة Group by لتسهيل رؤية تجمعات التطبيقات التي تعمل كهوية LOCALSYSTEM.

تظهر لقطة الشاشة أدناه مثالا على تجمع التطبيقات ("MyAppPool") الذي تم تكوينه للتشغيل ك LOCALSYSTEM. سيتم تشغيل أي تطبيقات تعمل داخل تجمع التطبيقات هذا كهوية SYSTEM.

تظهر لقطة الشاشة مثالا لتجمع التطبيقات ("MyAppPool") الذي تم تكوينه للتشغيل ك LOCALSYSTEM. سيتم تشغيل أي تطبيقات تعمل داخل تجمع التطبيقات هذا كهوية SYSTEM.

يمكنك أيضا الوصول إلى هذه المعلومات برمجيا من جلسة PowerShell غير مقيدة باستخدام البرنامج النصي أدناه.

Import-Module IISAdministration Get-IISAppPool | where {$_.ProcessModel.IdentityType -eq "LocalSystem"}

في جهاز تم تكوينه باستخدام تجمع تطبيقات "MyAppPool" على مستوى النظام كما هو موضح في لقطة الشاشة أعلاه، يطبع هذا البرنامج النصي PowerShell ما يلي، ويظهر أن "MyAppPool" قيد التشغيل ضمن هوية SYSTEM.

Name Status CLR Ver Pipeline Mode Start Mode ---- ------ ------- ------------- ---------- MyAppPool Started v4.0 Integrated OnDemand

خدمات Windows

إذا كانت .NET Framework أو . يتم تسجيل التطبيق المستند إلى NET كخدمة Windows، يمكنك استخدام مدير الخدمات لعرض الهوية المقترنة به.

من موجه أوامر غير مقيد، قم بتشغيل services.msc. يعرض هذا واجهة مستخدم مدير الخدمات.

إذا كان العمود Log On As يسرد "النظام المحلي" لهوية الخدمة، فإن الخدمة قيد التشغيل ضمن هوية SYSTEM.

يمكنك أيضا الاستعلام عن هذه البيانات عبر PowerShell باستخدام Get-Service cmdlet. على سبيل المثال، للاستعلام عن هذه المعلومات لخدمة تسمى MyService، استخدم الأمر التالي.

(Get-Service MyService).UserName -ieq "LocalSystem"

إذا تم تسجيل الخدمة للتشغيل ضمن هوية SYSTEM، فسيطبع هذا True إلى وحدة التحكم.

آليات أخرى

يمكن لأدوات مثل مدير المهام (taskmgr.exe) أو مستكشف عمليات Sysinternals أن تخبرك أيضا ما إذا كان التطبيق يعمل تحت هوية النظام.

في إدارة المهام، استخدم طريقة عرض التفاصيل لسرد جميع العمليات قيد التشغيل في النظام، ثم حدد موقع عملية الاهتمام وانظر إلى الإدخال ضمن عمود اسم المستخدم .

في إدارة المهام، استخدم طريقة عرض التفاصيل لسرد جميع العمليات قيد التشغيل في النظام، ثم حدد موقع عملية الاهتمام وانظر إلى الإدخال ضمن عمود اسم المستخدم.

إذا كانت قيمة اسم المستخدم تقرأ "SYSTEM"، يتم تشغيل العملية ضمن هوية SYSTEM.

أو، في Sysinternals Process Explorer، حدد موقع عملية الاهتمام وأدخل طريقة العرض Properties ، ثم انظر إلى حقل User ضمن علامة التبويب Image .

في Sysinternals Process Explorer، حدد موقع عملية الاهتمام وأدخل طريقة عرض Properties، ثم انظر إلى حقل User ضمن علامة التبويب Image.

إذا كانت قيمة المستخدم تقرأ "NT AUTHORITY\SYSTEM"، يتم تشغيل العملية ضمن هوية SYSTEM.

تغيير المسار المؤقت للعمليات على مستوى النظام

يوضح البرنامج النصي PowerShell أدناه كيفية إنشاء دليل جديد C:\NewSystemTemp\ وتقييد الوصول إلى الدليل إلى العمليات التي تعمل فقط ضمن هوية SYSTEM. لا تحاول تغيير قوائم التحكم في الوصول لدليل تم ملؤه بالفعل بالملفات.

يجب تشغيل هذا البرنامج النصي من جلسة عمل PowerShell غير مقيدة.

mkdir C:\NewSystemTemp\ $acl = New-Object System.Security.AccessControl.DirectorySecurity $acl.SetSecurityDescriptorSddlForm("O:SYG:SYD:PAI(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)") Set-Acl C:\NewSystemTemp\ -AclObject $acl

يمكنك التأكد من نجاح هذه العملية عن طريق تشغيل الأمر

icacls C:\NewSystemTemp\

الذي سينتج الإخراج التالي يظهر النجاح:

C:\NewSystemTemp\ NT AUTHORITY\SYSTEM:(OI)(CI)(F) BUILTIN\Administrators:(OI)(CI)(F) Successfully processed 1 files; Failed processing 0 files

بمجرد إنشاء الدليل، قم بتعيين متغير البيئة %SYSTEMTEMP% مع نطاق على مستوى النظام. يمكنك تعيين هذا عبر واجهة مستخدم النظام لوحة التحكم، أو يمكنك تعيينه برمجيا عبر PowerShell:

[Environment]::SetEnvironmentVariable("SYSTEMTEMP", "C:\NewSystemTemp", [EnvironmentVariableTarget]::Machine)

ثم أعد تشغيل الجهاز.

لن يؤدي تغيير متغير البيئة %SYSTEMTEMP% إلى تغيير القيمة المرجعة System.IO.Path.GetTempPath() لتطبيقات .NET Framework و.NET التي تعمل كهوية أخرى غير SYSTEM. ستستمر هذه التطبيقات في اتباع نفس منطق الحل الذي لديهم دائما، بما في ذلك احترام متغيرات البيئة %TMP% أو %TEMP% إذا كانت موجودة.

وبالمثل، لن يؤدي تعيين متغير البيئة %TMP% أو %TEMP% إلى تغيير القيمة المرجعة System.IO.Path.GetTempPath() لتطبيقات .NET Framework و.NET التي يتم تشغيلها كهوية SYSTEM.

لمزيد من المعلومات

لمزيد من المعلومات حول سلوكيات .NET Framework و.NET، راجع وثائق .NET على Path.GetTempPath.

لمزيد من المعلومات حول سلوك نظام التشغيل Windows الأساسي، راجع وثائق Windows على واجهة برمجة تطبيقات Win32 GetTempPath2.