متى يلزم امتياز المسؤول على Windows - UAC والمناطق المحميّة وكيفيّة التمييز في التصميم

في استشارات Windows تختلط أحاديث من هذا النوع كثيراً.

• متى يلزم «التشغيل كمسؤول»
• لماذا ما زال UAC يظهر رغم أن الحساب مسؤول
• هل التثبيت يحتاج المسؤول دائماً
• نريد الوضع في Program Files، فهل يلزم الرفع حتى وقت التشغيل
• فرق HKCU وHKLM، أين يؤثّر في الممارسة
• كيف يُبنى تطبيق يحتاج امتياز المسؤول «لبعض المعالجة فقط»

هذا الحديث لا يُحسَم بـ «هل ذلك الشخص مسؤول» وحده. في الواقع يُحسَم إلى حدّ بعيد بـ أين تكتب، ومن يتأثّر بالتغيير، وأيّ هدف محمي في نظام التشغيل تلمس.

flowchart TB
    accTitle: ما يحسم لزوم امتياز المسؤول
    accDescr: مخطّط يبيّن أن لزوم امتياز المسؤول لا يُحسَم بكون الشخص مسؤولاً وحده، بل يُحسَم إلى حدّ بعيد بأين تكتب ومن يتأثّر بالتغيير وأيّ هدف محمي في نظام التشغيل تلمس.
    a0["هل ذلك الشخص مسؤول"] -.-> a1["ذلك وحده لا يحسم"]
    b0["الأسئلة التي تؤثّر فعلاً"] --> b1["أين تكتب"]
    b0 --> b2["من يتأثّر بالتغيير"]
    b1 --> b3["أيّ هدف محمي في نظام التشغيل تلمس"]

الشكل 1: ما يحسم اللزوم ليس لقب المستخدم بل موضع الكتابة ونطاق التأثير والهدف المحمي.

ترتّب هذه المقالة المواضع التي يلزم فيها امتياز المسؤول على Windows من افتراضات UAC بالترتيب، وتلخّص عمليّاً حتى أين تكفي صلاحيات المستخدم القياسي، ومن أين يبدأ حديث الرفع. المحتوى يقوم على المعلومات الرسميّة من Microsoft التي يمكن التحقّق منها حتى مارس 2026.¹²³⁴⁵

1. الخلاصة أوّلاً

نرتّب أوّلاً خلاصة الممارسة فقط.

• لزوم امتياز المسؤول على Windows يُحسَم بـ «هل يؤثّر على نظام التشغيل أو الجهاز ككلّ» أكثر من «هل المعالجة متقدّمة».¹⁴
• المعالجة المغلقة في ملفّ التعريف الخاص بك وحدك، مثل استخدام %AppData% و%LocalAppData% وHKCU وDocuments، تكتمل عادة بلا امتياز مسؤول.⁶⁷
• بالمقابل، المعالجة التي تلمس الجهاز ككلّ أو جميع المستخدمين أو منطقة محميّة، مثل إعدادات على مستوى الجهاز في Program Files وWindows وSystem32 وHKLM وHKCR، وخدمة Windows، وبرنامج تشغيل النواة، والجدار الناري، ومهمّة بأعلى الصلاحيّات، يسهل أن تحتاج امتياز المسؤول.⁴⁶⁸⁹¹⁰
• المهم هنا أن انتماء المستخدم إلى مجموعة Administrators وكون ذلك التطبيق يعمل الآن برمز وصول مسؤول أمران مختلفان. عند تفعيل UAC تعمل العمليّات العاديّة حتى لمستخدم مسؤول بما يعادل مستخدماً قياسيّاً، ولا يحدث الرفع إلا عند الحاجة.²⁶
• التثبيت = المسؤول دائماً ليس صحيحاً. مثل تثبيت per-user، إن كان الافتراض الوضع تحت %LocalAppData% فهناك تصميم يوزَّع ويُحدَّث بلا امتياز مسؤول.¹¹¹²
• التطبيق «الذي يحتاج صلاحيات المسؤول كلّ مرّة لسبب ما» في الغالب يكتب بيانات وقت التشغيل إلى منطقة محميّة أو يعلن في البيان requireAdministrator / highestAvailable.⁴¹³
• من جهة الاتجاه أيضاً يميل Windows إلى الرفع الصريح في اللحظة المطلوبة فقط. Administrator protection (preview) في Windows 11 يبيّن هذا الاتّجاه بوضوح كبير.⁵

باختصار، الأعمليّ رؤية أن «هل يلزم امتياز المسؤول» يُحسَم بالحدّ الذي يلمسه التطبيق لا بلقب المستخدم.

flowchart TB
    accTitle: لزوم الرفع ينقسم بنطاق التأثير
    accDescr: مخطّط يبيّن أن لزوم امتياز المسؤول يُحسَم بما إذا كان يؤثّر على نظام التشغيل أو الجهاز ككلّ لا بما إذا كانت المعالجة متقدّمة، فالمعالجة المغلقة في ملفّ التعريف لا تلزم غالباً، والتي تلمس الجهاز ككلّ أو جميع المستخدمين أو منطقة محميّة يسهل أن تلزم.
    j1{"هل يؤثّر على نظام التشغيل أو الجهاز ككلّ"}
    j1 -->|"مغلق في ملفّ التعريف"| r1["يسهل الاكتمال بلا امتياز مسؤول"]
    j1 -->|"يلمس الجهاز ككلّ أو جميع المستخدمين أو منطقة محميّة"| r2["يسهل لزوم امتياز المسؤول"]
    r0["هل المعالجة متقدّمة"] -.-> r3["ليس معيار الحكم"]

الشكل 2: الحدّ الفاصل ليس تقدّم المعالجة بل نطاق تأثير التغيير.

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 22، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

2. ما معنى «يلزم امتياز المسؤول» أصلاً

ما نريد ترتيبه أوّلاً في هذا الحديث هو التفكير بفصل المستخدم عن العمليّة.

UAC في Windows وظيفة أمنيّة لمنع التغيير غير المشروع على نظام التشغيل. Microsoft Learn أيضاً توضّح أن UAC يُخطر عند إجراء تغيير يحتاج إذناً بمستوى المسؤول.¹

علاوة على ذلك، الشرح الرسمي لـ UAC يقول إن التطبيق الذي يحتاج رمز وصول مسؤول يطلب موافقة المستخدم النهائي، وإن العمليّة الابن ترث رمز وصول العمليّة الأب، والأب والابن يعملان بمستوى سلامة واحد.²

من هنا يتّضح أمران.

2.1 حتى «المستخدم المسؤول» لا يعمل كمسؤول طوال الوقت عادة

Microsoft Learn توضّح أن العمليّات التي يطلقها عضو مجموعة Administrators، عند تفعيل UAC، تعمل بصلاحيّات مستخدم قياسي ما لم تُرفَع خصوصاً.⁶

ذلك لأن رمزي وصول يُنشآن عند تسجيل دخول المستخدم المسؤول، وفي العادة يُستخدم الجانب المقيَّد فقط. بالرسم كالتالي.²

flowchart TD
    L["يسجّل المستخدم المسؤول الدخول"] --> S["Windows يجهّز رمزين"]
    S --> F["الرمز المصفّى<br/>يعادل مستخدماً قياسيّاً"]
    S --> A["رمز المسؤول الكامل<br/>يُستخدم عند الرفع فقط"]
    F --> N["إطلاق التطبيقات عادة<br/>المستكشف أيضاً من هنا"]
    N --> C["العمليّة الابن ترث رمز الأب<br/>لذا الابن أيضاً يعادل مستخدماً قياسيّاً"]
    N --> Q{"هل حاول لمس منطقة محميّة أو خدمة"}
    Q -- "لا" --> OK["يمكن التشغيل كما هو"]
    Q -- "نعم" --> P["مطالبة موافقة UAC"]
    P --> A
    A --> E["العمليّة المرفوعة وحدها<br/>تستطيع تغيير المنطقة المحميّة"]

الشكل 3: عند تسجيل دخول المستخدم المسؤول يُنشأ رمزان، وفي العادة يعمل الجانب المعادل للمستخدم القياسي.

«UAC يظهر كلّ مرّة رغم أنّي مستخدم مسؤول» لأن عمليّة لا تُنفَّذ إلا برمز المسؤول الكامل وصلت إلى موضع أُطلق بالرمز المصفّى. الرمز يُحدَّد عند الإطلاق، لذا يُقرأ من هنا أيضاً أن إضافته لاحقاً لا تكون إلا بإطلاق عمليّة جديدة.

بعبارة أخرى، التالي عادي:

• حساب Windows لديك مسؤول
• لكن التطبيق الذي أطلقته بالنقر المزدوج الآن غير مرفوع
• لذلك يظهر UAC فقط لحظة العملية التي تحتاج امتياز المسؤول

«أنا مسؤول، فلماذا ما زالت الصلاحيّات ناقصة» سلوك طبيعي جدّاً على Windows.

2.2 لا يمكن داخل العمليّة نفسها «جعل هذه المعالجة وحدها مسؤولة فجأة»

UAC ليس سحراً على مستوى الدالة، بل حديث بأيّ رمز تعمل العمليّة. العمليّات الأب والابن ترث الرمز، لذا لا يمكن تصميم جعل بعض الدوال داخل عمليّة UI غير مرفوعة مسؤولة فقط لحظة ضغط زرّ معيّن في العمليّة نفسها.²

إن لزم فاستخدم وحدة تشغيل أخرى مثل:

• القطع إلى EXE آخر
• استخدام خدمة
• استخدام مهمّة بأعلى الصلاحيّات
• استخدام COM مرفوع

¹⁴

التصميم دون معرفة هذا الافتراض ينتهي عادة باستشارة مؤلمة قليلاً من نوع «نريد تشغيل هذا الزرّ وحده كمسؤول».

flowchart TB
    accTitle: لا يمكن رفع جزء فقط داخل العمليّة
    accDescr: مخطّط يبيّن أن UAC حديث الرمز الذي تعمل به العمليّة، وأن العمليّات الأب والابن ترث الرمز، فلا يمكن جعل بعض الدوال داخل عمليّة UI غير مرفوعة مسؤولة، وإن لزم فافصل إلى وحدة تشغيل أخرى: EXE آخر أو خدمة أو مهمّة بأعلى الصلاحيّات أو COM مرفوع.
    p1["عمليّة UI غير مرفوعة"] -.-> p2["جعل بعض الدوال وحدها مسؤولة غير ممكن"]
    p1 --> p3["إن لزم فإلى وحدة تشغيل أخرى"]
    p3 --> q1["القطع إلى EXE آخر"]
    p3 --> q2["استخدام خدمة"]
    q1 --> q3["استخدام مهمّة بأعلى الصلاحيّات"]
    q2 --> q4["استخدام COM مرفوع"]

الشكل 4: الرفع على مستوى العمليّة، لذا افصل المعالجة اللازمة إلى وحدة تشغيل أخرى.

النقطتان المذكورتان هنا مهد لسوء الفهم أيضاً، لذا يُعاد تناولهما بشكل أسئلة وأجوبة في «سوء فهم شائع» في الفصل 9. عند الشرح داخليّاً يفترض أن الفصل 9 أقصر وأسهل اقتباساً.

3. بماذا يُحسَم - طريقة التمييز أوّلاً

أوضح طريقة تمييز هي الثلاث التالية.

1. أين تكتب
2. من يتأثّر بالتغيير
3. هل تلمس هدفاً محميّاً في نظام التشغيل

3.1 مناطق نموذجيّة يلزم الرفع للكتابة إليها

كافتراض للفصول التالية، نضع أوّلاً قائمة بالمناطق التي «محاولة الكتابة إليها تحتاج رفعاً». الحديث من الفصل 4 فما فوق يقع تقريباً كلّه في أحد صفوف هذا الجدول.

ما هو «غير لازم» بوضوح هو السطر الأخير وحده، وC:\ProgramData مشروط، والباقي كلّه جانب الرفع. بالمقابل، هل يمكن تقريب موضع كتابة التطبيق إلى هذا السطر الأخير و%ProgramData% يحسم لزوم الرفع تقريباً.⁴⁶⁷

flowchart TB
    accTitle: لزوم الرفع يُحسَم بإمكان تقريب موضع الكتابة
    accDescr: مخطّط يبيّن أن تقريب موضع كتابة التطبيق إلى تحت ملفّ التعريف وProgramData يقترب من تصميم بلا رفع، وأن البقاء على الكتابة إلى منطقة محميّة يُبقي الجانب الذي يحتاج رفعاً.
    w1["اجرد مواضع كتابة التطبيق"] --> j1{"هل يمكن التقريب إلى تحت ملفّ التعريف وProgramData"}
    j1 -->|"يمكن التقريب"| r1["يقترب من تصميم بلا رفع"]
    j1 -->|"يبقى في منطقة محميّة"| r2["يبقى في الجانب الذي يحتاج رفعاً"]

الشكل 5: ما يحسم لزوم الرفع تقريباً هو إلى أيّ حدّ يمكن تقريب موضع الكتابة.

3.2 جدول حكم حسب المراد

إن جُعل قابلاً للجذب من جانب «ما تريد فعله» يصير كالتالي. الحكم وُحِّد في ثلاثة: إلزامي / حسب الوضع / غير لازم.

بتلخيص تقريبي:

• تغيير من أجلك أنت يسهل اكتماله بمستخدم قياسي
• تغيير من أجل الجميع يسهل أن يتدخّل المسؤول
• لمس حدّ الأمان في نظام التشغيل يلزم المسؤول

النظر إلى هذه الثلاث أوّلاً وحده يسهّل كثيراً شرح «لماذا يظهر UAC».

flowchart TB
    accTitle: التمييز حسب من أجل من التغيير
    accDescr: مخطّط يبيّن تمييزاً تقريبيّاً لكن نافعاً في الممارسة: التغيير من أجلك أنت يسهل اكتماله بمستخدم قياسي، والتغيير من أجل الجميع يسهل أن يتدخّل المسؤول، ولمس حدّ الأمان في نظام التشغيل يلزم المسؤول.
    q1{"من أجل من التغيير"}
    q1 -->|"من أجلك أنت"| r1["يسهل الاكتمال بمستخدم قياسي"]
    q1 -->|"من أجل الجميع"| r2["يسهل أن يتدخّل المسؤول"]
    q1 -->|"حدّ الأمان في نظام التشغيل"| r3["يلزم المسؤول"]

الشكل 6: النظر أوّلاً إلى «من أجل من التغيير» وحده يسهّل شرح سبب ظهور UAC.

4. أمثلة نموذجيّة يسهل أن يلزم فيها امتياز المسؤول

4.1 التثبيت والتحديث وإلغاء التثبيت لجميع المستخدمين

شرح هندسة UAC في Microsoft Learn يقول إن كثيراً من المثبِّتات تكتب إلى دلائل النظام أو مفاتيح السجلّ، فلا يكفي حقّ الوصول للمستخدم القياسي، ويكتشف Windows برنامج التثبيت ويطلب الرفع.³

النقطة هنا أن المثبِّت ليس «عظيماً لأنّه مثبِّت»، بل الرفع لازم لأن موضع الكتابة منطقة محميّة.

نموذجيّاً هذا الجانب:

• الوضع في Program Files
• كتابة معلومات على مستوى الجهاز إلى HKLM
• تسجيل COM أو دمج لجميع المستخدمين
• إدخال خدمة أو برنامج تشغيل
• امتلاك مسار تحديث للجهاز ككلّ

هذا الجانب يسهل أن يحتاج امتياز المسؤول.³⁸

flowchart TB
    accTitle: سبب طلب المثبِّت للرفع
    accDescr: مخطّط يبيّن أن الرفع ليس لأن المثبِّت عظيم، بل لأن الكتابة إلى دلائل النظام أو مفاتيح السجلّ مثل Program Files وHKLM لا تعطي المستخدم القياسي حقّ وصول كافياً، فيكتشف Windows برنامج التثبيت ويطلب الرفع.
    i1["كثير من المثبِّتات"] --> i2["تكتب إلى دلائل النظام أو مفاتيح السجلّ"]
    i2 --> i3["المستخدم القياسي بلا حقّ وصول كافٍ"]
    i3 --> i4["Windows يكتشف ويطلب الرفع"]
    i1 -.-> i5["ليس لأن المثبِّت عظيم"]

الشكل 7: الرفع لازم لأن موضع كتابة المثبِّت منطقة محميّة.

4.2 كتابة بيانات وقت التشغيل إلى Program Files أو HKLM

هذا أيضاً كثير جدّاً. دليل تصميم UAC من Microsoft يقول إن الرفع غير اللازم ينبغي إلغاؤه، وإن كثيراً من البرمجيّات القديمة تحتاج امتياز المسؤول بلا داعٍ لأنّها تكتب إلى HKLM / HKCR أو Program Files / Windows System folders.⁴

علاوة على ذلك، شرح المستخدم القياسي ينصّ على أنّه لا يستطيع الكتابة إلى مجلّد Program Files أو HKEY_LOCAL_MACHINE، ولا يستطيع أيضاً معالجة تغيّر النظام.⁶

أي أن وضع بيانات تتغيّر وقت التشغيل مثل:

• ملفّ الإعداد
• السجلّ
• الذاكرة المؤقّتة
• الحالة لكلّ مستخدم
• تاريخ الاستخدام الأخير

في مجلّد موضع التثبيت أو HKLM وحده يسهل أن يصير «هذا التطبيق لا يعمل ما لم يُطلَق كمسؤول».

وهذا كثيراً ما يحدث لا لأن التطبيق موجَّه للمسؤول حقّاً، بل لسوء اختيار موضع الحفظ وحده.

flowchart TB
    accTitle: ماذا يحدث عند كتابة بيانات وقت التشغيل إلى منطقة محميّة
    accDescr: مخطّط يبيّن أن وضع بيانات تتغيّر وقت التشغيل مثل ملفّ الإعداد والسجلّ والذاكرة المؤقّتة والتاريخ في مجلّد موضع التثبيت أو HKLM وحده يسهل أن يصير تطبيقاً لا يعمل ما لم يُطلَق كمسؤول، وأن السبب غالباً اختيار موضع الحفظ لا كون التطبيق موجَّهاً للمسؤول.
    d1["بيانات وقت التشغيل مثل الإعداد والسجلّ والذاكرة المؤقّتة والتاريخ"] --> d2["وضعها في مجلّد موضع التثبيت أو HKLM"]
    d2 --> d3["يصير تطبيقاً لا يعمل ما لم يُطلَق كمسؤول"]
    d3 -.-> d4["السبب غالباً اختيار موضع الحفظ وحده"]

الشكل 8: ماهيّة «يلزم المسؤول كلّ مرّة» غالباً موضع بيانات وقت التشغيل.

4.3 تسجيل خدمة Windows أو تغيير تكوينها

الخدمة هدف إدارة لنظام التشغيل، لذا لا تُلمَس بخفّة بالطبع.

وثائق حقوق وصول مدير التحكّم في الخدمات الرسميّة تقول إن استدعاء CreateService يحتاج SC_MANAGER_CREATE_SERVICE، وإن من يستطيع فتح المقبض الصالح لـ CreateService هو العمليّة ذات Administrator privileges وحدها.⁸

كذلك يُقال إن SERVICE_CHANGE_CONFIG اللازم لـ ChangeServiceConfig / ChangeServiceConfig2 ينبغي منحه للمسؤول فقط لأنّه يستطيع تغيير EXE الذي ينفّذه النظام.⁸

لذلك معالجة من هذا النوع تفترض امتياز المسؤول:

• تسجيل الخدمة
• تغيير ملفّ تشغيل الخدمة أو نوع الإطلاق
• حذف الخدمة
• تغيير واصف أمان الخدمة

flowchart TB
    accTitle: تشغيل الخدمة وامتياز المسؤول
    accDescr: مخطّط يبيّن أن استدعاء CreateService يحتاج SC_MANAGER_CREATE_SERVICE، وأن من يفتح ذلك المقبض هو عمليّة المسؤول وحدها، وأن SERVICE_CHANGE_CONFIG اللازم لتغيير التكوين ينبغي منحه للمسؤول فقط لأنّه يستطيع تغيير EXE الذي ينفّذه النظام.
    s1["تسجيل الخدمة"] --> s2["يلزم SC_MANAGER_CREATE_SERVICE"]
    s2 --> s3["من يفتح المقبض عمليّة المسؤول وحدها"]
    t1["تغيير تكوين الخدمة"] --> t2["يلزم SERVICE_CHANGE_CONFIG"]
    t2 --> t3["ينبغي منحه للمسؤول فقط"]

الشكل 9: الخدمة هدف إدارة لنظام التشغيل، والتسجيل وتغيير التكوين يفترضان امتياز المسؤول.

4.4 إدخال برنامج تشغيل للنواة

Microsoft Learn توضّح أن المستخدم القياسي لا يستطيع تنفيذ مهام تغيّر النظام مثل تثبيت kernel-mode driver.⁶

هذا حدّ واضح جدّاً. برنامج التشغيل يعمل في جانب النواة، فلا يُعامَل في الصف نفسه مع «حفظ إعداد تطبيق مستخدم عادي».

• إدخال برنامج تشغيل جهاز
• إدخال برنامج تشغيل افتراضي أو مرشِّح
• تغيير مكوّن يتعلّق بالإقلاع أو الإدخال/الإخراج

يجوز اعتبار أن هذه المعالجة تحتاج امتياز المسؤول.

flowchart TB
    accTitle: حدّ واضح اسمه برنامج تشغيل النواة
    accDescr: مخطّط يبيّن أن برنامج التشغيل يعمل في جانب النواة فلا يُعامَل في الصف نفسه مع حفظ إعداد تطبيق مستخدم عادي، وأن مهام تغيير النظام مثل تثبيت kernel-mode driver لا ينفّذها المستخدم القياسي.
    k1["إدخال برنامج التشغيل"] --> k2["إدخال مكوّن يعمل في جانب النواة إلى النظام"]
    k2 --> k3["مهمّة تغيّر النظام"]
    k3 --> k4["لا ينفّذها المستخدم القياسي"]
    k1 -.-> k5["لا يُعامَل في الصف نفسه مع حفظ إعداد تطبيق المستخدم"]

الشكل 10: ما يلمس النواة في أوضح حدّ جانب المسؤول.

4.5 إعداد الجدار الناري والمهام عالية الصلاحيّات

الجدار الناري أيضاً جزء من حدّ أمان نظام التشغيل. إجراءات إعداد الجدار الناري في Microsoft Learn تنصّ على أن تشغيل Windows Firewall with Advanced Security على جهاز واحد يحتاج administrative rights على ذلك الجهاز.⁹

كذلك بشأن جدولة المهام، يُعرَّف أن TASK_RUNLEVEL_LUA بأدنى صلاحيّات وTASK_RUNLEVEL_HIGHEST بأعلى صلاحيّات، ووثائق schtasks أيضاً تقول إن جدولة / عرض / تغيير جميع المهام على الحاسوب المحلّي تحتاج العضويّة في مجموعة Administrators.¹⁰

بالتلخيص، تكوين من هذا النوع في الجانب الذي يحتاج امتياز المسؤول:

• إضافة قواعد Windows Firewall أو تغييرها
• تسجيل معالجة معيّنة كمهمّة بأعلى الصلاحيّات
• تشغيل وظيفة بمستخدم آخر أو SYSTEM

flowchart TB
    accTitle: الجدار الناري والمهام عالية الصلاحيّات
    accDescr: مخطّط يبيّن أن تغيير قواعد الجدار الناري يحتاج administrative rights على ذلك الجهاز، وأن التشغيل بأعلى الصلاحيّات في جدولة المهام وتغيير جميع المهام يفترضان العضويّة في مجموعة Administrators، وكلاهما في جانب امتياز المسؤول.
    f1["تغيير قواعد الجدار الناري"] --> f2["تلزم administrative rights على ذلك الجهاز"]
    g1["تسجيل مهمّة وتشغيلها بأعلى الصلاحيّات"] --> g2["التسجيل والتشغيل يفترضان الرفع"]
    f2 --> h1["جانب المسؤول كجزء من حدّ أمان نظام التشغيل"]
    g2 --> h1

الشكل 11: الجدار الناري والمهام عالية الصلاحيّات أيضاً جانب المسؤول كحدّ أمان لنظام التشغيل.

5. أمثلة نموذجيّة يكتمل فيها بلا امتياز مسؤول في الواقع كثيراً

يسهل أن يبدو أن «Windows يطلب المسؤول فوراً»، لكن في الواقع الجزء الذي يمكن تصميمه بلا امتياز مسؤول أكثر ممّا يُظنّ.

5.1 الإعداد والذاكرة المؤقّتة والسجلّ الخاص بك

Microsoft Learn توضّح أنّه بدل الاتّكال على الافتراضيّة للتوافق، ينبغي أن يحفظ التطبيق في per-user location أو في computer location داخل %alluserprofile% مع ضبط ACL صحيحاً.⁷

عمليّاً يسهل الترتيب بالتقسيم التالي.

• خاص بالمستخدم: %AppData%, %LocalAppData%, HKCU
• مشترك لكن يُحدَّث وقت التشغيل: %ProgramData% + تصميم ACL
• ملفّ التشغيل نفسه: منطقة محميّة مثل Program Files

إن أمكن هذا الفصل يمكن جعل تثبيت التطبيق نفسه بمسؤول، والاستخدام العادي بلا مسؤول.

flowchart TB
    accTitle: الفصل الثلاثي للبيانات
    accDescr: مخطّط يبيّن أن فصل البيانات الخاصّة بالمستخدم إلى AppData أو HKCU، والبيانات المشتركة التي تُحدَّث وقت التشغيل إلى ProgramData وتصميم ACL، وملفّ التشغيل نفسه إلى منطقة محميّة مثل Program Files، إن أمكن يجعل التثبيت بمسؤول والاستخدام العادي بلا مسؤول.
    z0["ما يعالجه التطبيق"] --> z1["بيانات خاصّة بالمستخدم"]
    z0 --> z2["بيانات مشتركة تُحدَّث وقت التشغيل"]
    z0 --> z3["ملفّ التشغيل نفسه"]
    z1 --> y1["AppData / HKCU"]
    z2 --> y2["ProgramData + تصميم ACL"]
    z3 --> y3["منطقة محميّة مثل Program Files"]
    y2 -.-> y4["الاستخدام العادي يمكن بلا مسؤول"]

الشكل 12: إن أمكن هذا الفصل الثلاثي، فالرفع يلزم فقط لحظة التثبيت.

5.2 تثبيت per-user والتحديث

وثائق Microsoft الرسميّة أيضاً تظهر فيها أمثلة الوضع per-user بشكل عادي.

مثلاً وثائق عميل Remote Desktop تقول إن تثبيت per-user يثبَّت تحت LocalAppData في ملفّ تعريف كل مستخدم، ويستطيع المستخدم التحديث بلا صلاحيات مسؤول.¹¹

كذلك وثائق OneDrive تقول إن الافتراضي تثبيت per-user، وإن تثبيت per-machine ينفّذ الأمر مع /allusers فينتج مطالبة UAC. علاوة على ذلك، per-user يدخل تحت %localappdata% وper-machine تحت Program Files.¹²

ما يتّضح من هنا أن كلمة «تثبيت» وحدها لا تحسم لزوم امتياز المسؤول.

• إن وضع كل مستخدم في منطقته، قد يكتمل بلا مسؤول
• إن وضع في منطقة مشتركة لجميع المستخدمين، يسهل لزوم المسؤول

المهم تقرير per-user أو per-machine أوّلاً.

flowchart TB
    accTitle: كلمة تثبيت لا تحسم اللزوم
    accDescr: مخطّط يبيّن أن تثبيت per-user الذي يضع كل مستخدم في منطقته قد يكتمل بلا مسؤول، وأن تثبيت per-machine الذي يضع في منطقة مشتركة لجميع المستخدمين يسهل لزوم المسؤول، فكلمة تثبيت وحدها لا تحسم لزوم امتياز المسؤول.
    i0{"أيّ طريقة وضع"}
    i0 -->|"per-user"| i1["كل مستخدم يضع في منطقته"]
    i0 -->|"per-machine"| i2["الوضع في منطقة مشتركة لجميع المستخدمين"]
    i1 --> i3["قد يكتمل بلا مسؤول"]
    i2 --> i4["يسهل لزوم المسؤول"]

الشكل 13: ليس «التثبيت = المسؤول دائماً»، بل يُحسَم بـ per-user أو per-machine.

5.3 تشغيل UI عادي ومنطق العمل

بالمقابل، معالجة من هذا النوع لا تحتاج امتياز المسؤول بذاتها.

• فتح مستند أو صورة
• تحرير ملفّ تحت ملفّ التعريف الخاص بك
• اتّصال HTTP أو اتّصال قاعدة بيانات
• تنفيذ منطق العمل
• عرض النتيجة على الشاشة
• قراءة إعداد خاص بك وكتابته

ومع ذلك إن لزم «تشغيل التطبيق كلّه كمسؤول»، فالسبب غالباً ليس وظيفة التطبيق نفسها بل بعض المعالجة المحيطة تلمس منطقة محميّة.

flowchart TB
    accTitle: السبب ليس الوظيفة نفسها بل المعالجة المحيطة
    accDescr: مخطّط يبيّن أن فتح مستند وتنفيذ منطق العمل وقراءة إعداد خاص وكتابته لا تحتاج امتياز المسؤول بذاتها، فإن لزم مع ذلك تشغيل التطبيق كلّه كمسؤول فالسبب غالباً أن بعض المعالجة المحيطة تلمس منطقة محميّة.
    m1["فتح مستند والاتّصال وتنفيذ منطق العمل"] --> m2["بذاتها لا تحتاج امتياز المسؤول"]
    m3["ومع ذلك يطلب التطبيق كلّه التشغيل كمسؤول"] --> m4["بعض المعالجة المحيطة تلمس منطقة محميّة"]
    m4 -.-> m5["السبب ليس الوظيفة نفسها"]

الشكل 14: إن لزم المسؤول رغم أن الأصل معالجة عاديّة، فاشِكّ في موضع كتابة المعالجة المحيطة.

6. لماذا يُقال «هذا التطبيق بمسؤول»

6.1 الإعلان عن requireAdministrator في البيان

في بيان التطبيق يمكن إعلان مستوى الصلاحيّات اللازم بـ requestedExecutionLevel. Microsoft Learn تعرّف الثلاثة التالية.¹³

• asInvoker: يعمل بنفس صلاحيّات عمليّة المصدر
• highestAvailable: يعمل بأعلى صلاحيّات ممكنة
• requireAdministrator: يعمل بصلاحيّات المسؤول

إن صار التطبيق requireAdministrator، الرفع مفترض عند كل إطلاق. حتى highestAvailable قد يتدخّل الرفع حسب البيئة.¹³

لذلك أوضح إجابة لـ «لماذا يظهر UAC كلّ مرّة» هي لأن ذلك التطبيق أعلن ذلك.

flowchart TB
    accTitle: إعلانات requestedExecutionLevel الثلاثة
    accDescr: مخطّط يبيّن أن requestedExecutionLevel في بيان التطبيق ثلاثة: asInvoker وhighestAvailable وrequireAdministrator، وأن requireAdministrator يفترض الرفع عند كل إطلاق، وأن highestAvailable قد يتدخّل فيه الرفع حسب البيئة.
    a1["requestedExecutionLevel في البيان"] --> b1["asInvoker"]
    a1 --> b2["highestAvailable"]
    a1 --> b3["requireAdministrator"]
    b1 --> c1["نفس صلاحيّات المصدر"]
    b2 --> c2["قد يتدخّل الرفع حسب البيئة"]
    b3 --> c3["الرفع مفترض عند كل إطلاق"]

الشكل 15: أوضح سبب لظهور UAC كلّ مرّة هو إعلان البيان.

6.2 الوقوع في installer detection في Windows

شرح هندسة UAC يقول إن في Windows installer detection technology، وإن كثيراً من برامج التثبيت تحتاج رفعاً لأنّها تكتب إلى protected system locations.³

وليس ذلك لمجرّد أن الاسم setup.exe، بل Windows يحكم إلى حدّ ما بحدس أن «هذا يشبه مثبِّتاً». الوثائق الرسميّة تذكر الشروط التالية.³

• ملفّ تشغيل 32-bit
• لا سمة requestedExecutionLevel
• عمليّة تفاعليّة من مستخدم قياسي مع تفعيل UAC
• تضمين اسم الملفّ كلمات مثل install وsetup وupdate، إلخ

لذلك طلب SetupLauncher.exe أو Updater.exe الرفع فجأة ليس غريباً كتصميم جانب Windows.

flowchart TB
    accTitle: شروط الوقوع في installer detection
    accDescr: مخطّط يبيّن أن installer detection في Windows يحكم بحدس أنّه يشبه مثبِّتاً من شروط مثل ملفّ تشغيل 32-bit بلا سمة requestedExecutionLevel وعمليّة تفاعليّة من مستخدم قياسي مع تفعيل UAC واسم ملفّ يتضمّن install أو setup أو update، فيطلب الرفع.
    c1["ملفّ تشغيل 32-bit"] --> e1["يُحكَم بأنّه يشبه مثبِّتاً"]
    c2["لا سمة requestedExecutionLevel"] --> e1
    c3["اسم الملفّ يتضمّن install / setup / update وما شابه"] --> e1
    e1 --> e2["يُطلَب الرفع"]

الشكل 16: تركيبة الاسم والسمة وحدها قد تُعامَل كمثبِّت فيُطلَب الرفع.

6.3 تطبيق قديم «كان يعمل مصادفة» بالافتراضيّة

هنا يسهل سوء الفهم جدّاً.

Microsoft Learn توضّح أن UAC يوفّر افتراضيّة للملفّات والسجلّ لتطبيق غير متوافق يحاول الكتابة إلى منطقة محميّة. وفي الوقت نفسه تنصّ أيضاً على أن هذا إجراء توافق قصير الأجل لا حلّ طويل الأجل.³⁷

علاوة على ذلك للافتراضيّة قيود.

• لا تُطبَّق على تطبيق مرفوع
• تُطبَّق على تطبيقات 32-bit فقط
• تُعطَّل إن وُجد بيان يتضمّن requestedExecutionLevel
• ينبغي أصلاً أن يُصلَح التطبيق ليكتب إلى موضع الحفظ الصحيح

هذه الشروط.³⁷

أي أن تطبيقاً قديماً بـ 32 بت قد يبدو «كان يكتب إلى Program Files بلا مسؤول»، لكنّه ربما لم يكن يكتب صحيحاً، بل أُفلت إلى VirtualStore.

لذلك في توقيت مثل:

• التحويل إلى 64 بت
• إضافة بيان
• تغيير طريقة البناء
• التقدّم في الامتثال لـ UAC

قد يظهر فجأة «خطأ تصميم موضع الحفظ» الذي لم يكن يظهر سابقاً.

flowchart TB
    accTitle: مسار ظهور «كان يعمل مصادفة» بالافتراضيّة
    accDescr: مخطّط يبيّن أن تطبيقاً غير متوافق بـ 32 بت يحاول الكتابة إلى منطقة محميّة يبدو أنّه يعمل بإفلاته إلى VirtualStore عبر افتراضيّة الملفّات والسجلّ، وأن هذا إجراء توافق قصير الأجل، فيتوقّف عمل الافتراضيّة عند التحويل إلى 64 بت أو إضافة بيان ويظهر خطأ تصميم موضع الحفظ فجأة.
    v1["تطبيق غير متوافق بـ 32 بت يحاول الكتابة إلى منطقة محميّة"] --> v2["الافتراضيّة تفلت إلى VirtualStore"]
    v2 --> v3["يبدو أنّه يعمل رغم أنّه لم يكتب صحيحاً"]
    v3 --> v4["التحويل إلى 64 بت أو إضافة بيان يوقف عمل الافتراضيّة"]
    v4 --> v5["خطأ تصميم موضع الحفظ يظهر فجأة"]

الشكل 17: الافتراضيّة إجراء مؤقّت، لذا يظهر خطأ التصميم لحظة تغيّر البيئة.

6.4 موضع اللمس وقت التشغيل سيّئ أصلاً

في الممارسة هذا في النهاية الأكثر.

• حفظ الإعداد بجانب EXE
• إخراج السجلّ إلى موضع التثبيت
• صنع ملفّ مؤقّت تحت Program Files
• كتابة الحالة لكلّ مستخدم إلى HKLM

بهذا التكوين يصير شكلاً صعب التعامل جدّاً: التطبيق نفسه UI عادي لكن الإطلاق يحتاج امتياز المسؤول.⁴⁶

حالة «المسؤول لأن موضع الحفظ سيّئ» لا «المسؤول لأن تلك المعالجة متقدّمة» كثيرة حقّاً.

6.5 إجراء لمعرفة أيّاً من هذه ينطبق على تطبيقك

من 6.1 إلى 6.4 «أنواع السبب»، لكن التحقيق الفعلي يحتاج تأكيد أيّاً منها ينطبق على تطبيقك. يكفيان هذان بالترتيب.

الإجراء 1: انظر إلى requestedExecutionLevel في البيان

أوّلاً تأكّد أن التطبيق لم يعلن الرفع بنفسه. البيان المضمَّن في EXE يُستخرَج بـ mt.exe من Windows SDK.

mt.exe -inputresource:MyApp.exe;#1 -out:MyApp.manifest

#1 هو معرّف مورد البيان المضمَّن في ملفّ التشغيل. انظر في XML المستخرَج إن وُجد سطر من هذا النوع.

<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />

إن كان requireAdministrator فالسبب 6.1 ثابت. إن كان asInvoker فليس من الإعلان فانتقل إلى الإجراء 2. قد لا يكون البيان نفسه مضمَّناً. هذه أيضاً معلومة مهمّة: ملفّ تشغيل 32 بت بلا requestedExecutionLevel قد يقع في installer detection في 6.2 وفي الافتراضيّة في 6.3 كليهما.³

الإجراء 2: انظر إن وُجدت نسخة في VirtualStore

ثانياً انظر إن كانت الملفّات التي ظننت أنّك كتبتها إلى منطقة محميّة قد افتُرضت في الواقع. موضع إعادة التوجيه ثابت.

dir /s /a "%LocalAppData%\VirtualStore"

إن اصطفّت هنا ملفّات إعداد تطبيقك أو سجلّاته، فمعنى ذلك أن ذلك التطبيق لم يكن يكتب إلى Program Files، بل أُفلت إلى نسخة لكلّ مستخدم. مثلاً الكتابة إلى C:\Program Files\Contoso\Settings.ini تُحوَّل إلى %LocalAppData%\VirtualStore\Program Files\Contoso\Settings.ini.³

موضع الافتراضيّة في جانب السجلّ مماثل: الكتابة إلى HKEY_LOCAL_MACHINE\Software تُحوَّل إلى HKEY_USERS\<SID المستخدم>_Classes\VirtualStore\Machine\Software. إن نظرت من المستخدم الحالي، فتح HKEY_CURRENT_USER\Software\Classes\VirtualStore\Machine\Software في محرّر السجلّ يُظهر الشيء نفسه.⁷

بهذين يتّضح إن كان سبب «يلزم صلاحيات المسؤول» إعلاناً أم موضع حفظ. إن كان موضع الحفظ، فالأصل تصحيح الموضع كما في 7.3، وإضافة الرفع ليست معالجة.

flowchart TB
    accTitle: إجراءان لتأكيد السبب
    accDescr: مخطّط يبيّن أنّك تستخرج أوّلاً البيان المضمَّن في EXE بـ mt.exe وتنظر إلى requestedExecutionLevel، فإن كان requireAdministrator فالسبب الإعلان ثابت، وإن كان asInvoker تؤكّد إن وُجدت نسخة تطبيقك في VirtualStore، فإن وُجدت فالسبب موضع الحفظ والأصل تصحيح الموضع.
    s1["الإجراء 1: انظر إلى requestedExecutionLevel في البيان"] --> j1{"ماذا أُعلن"}
    j1 -->|"requireAdministrator"| r1["السبب الإعلان ثابت"]
    j1 -->|"asInvoker أو بلا إعلان"| s2["الإجراء 2: أكّد نسخة VirtualStore"]
    s2 -->|"توجد نسخة"| r2["السبب موضع الحفظ"]
    r2 --> r3["الأصل تصحيح الموضع (إضافة الرفع ليست معالجة)"]

الشكل 18: بإجراءَي التأكيد ينقسم السبب بوضوح إلى إعلان أو موضع حفظ.

7. أيّ تصميم يقلّل الرفع غير اللازم

7.1 الأساس asInvoker

ما لم يكن التطبيق كلّه أداة إدارة نظام حقّاً، فالخطّ الأساسي تشغيل تطبيق UI عادي بلا رفع. من معنى البيان أيضاً، asInvoker إعلان «يعمل بنفس صلاحيّات المصدر».¹³

تشغيل كلّ شيء بمسؤول حتى تشغيل الشاشة العادي ومنطق العمل وحفظ الإعداد لكلّ مستخدم يزيد مشكلات:

• يتّسع سطح الهجوم
• يصعب شرح التشغيل
• يظهر UAC كلّ مرّة
• يختفي «أيّ معالجة تحتاج المسؤول حقّاً»

دليل تصميم UAC من Microsoft أيضاً يقول إن الرفع غير اللازم ينبغي إلغاؤه، وإن امتياز المسؤول ينبغي أن يقتصر على المهام اللازمة حقّاً.⁴

flowchart TB
    accTitle: المشكلات التي تزيد عند تشغيل الكلّ بمسؤول
    accDescr: مخطّط يبيّن أن تشغيل الكلّ بمسؤول حتى تشغيل الشاشة العادي ومنطق العمل يتّسع معه سطح الهجوم ويصعب شرح التشغيل ويظهر UAC كلّ مرّة ويختفي أيّ معالجة تحتاج المسؤول حقّاً، لذا الخطّ الأساسي تشغيل تطبيق UI عادي بلا رفع.
    a1["تشغيل الكلّ بمسؤول"] --> b1["يتّسع سطح الهجوم"]
    a1 --> b2["يظهر UAC كلّ مرّة"]
    b1 --> b3["يصعب شرح التشغيل"]
    b2 --> b4["تختفي المعالجة اللازمة حقّاً"]
    b3 --> c1["الخطّ الأساسي الإبقاء بلا رفع بـ asInvoker"]
    b4 --> c1

الشكل 19: الأساس asInvoker، والرفع يُضيَّق إلى المهام اللازمة حقّاً فقط.

7.2 افصل المعالجة التي تحتاج المسؤول وحدها إلى وحدة تشغيل أخرى

Microsoft Learn تنصّ صراحة على نموذج يشغّل التطبيق كتطبيق مستخدم قياسي ويفصل الجزء اللازم فقط، حتى إن كان فيه معالجة تحتاج امتياز المسؤول.¹⁴

النموذجيّة أربعة:

• Administrator Broker Model تطبيق UI لمستخدم قياسي + helper EXE للمسؤول
• Operating System Service Model UI مستخدم قياسي + خدمة مقيمة
• Elevated Task Model UI مستخدم قياسي + مهمّة مجدولة بأعلى الصلاحيّات
• Administrator COM Object Model UI مستخدم قياسي + COM مرفوع

الاستخدام التقريبي كالتالي.

• إن لزم تشغيل مسؤول أحياناً فقط فـ helper EXE
• إن كان دائماً / غير مراقب / متكرّراً فخدمة
• إن كانت وظيفة نمطيّة قصيرة فمهمّة highest
• إن كان بافتراض COM قائم فـ COM مرفوع

تجسيد هذا التصميم في تطبيق Windows يعالَج أيضاً بالتفصيل في مقالة منفصلة: كيف تعزل العمل الذي يحتاج إلى المسؤول فقط داخل تطبيقات Windows

flowchart TB
    accTitle: استخدام نماذج الفصل الأربعة
    accDescr: مخطّط يبيّن استخدام نماذج تشغيل كتطبيق مستخدم قياسي وفصل معالجة المسؤول وحدها: helper EXE في Administrator Broker Model إن لزم تشغيل مسؤول أحياناً فقط، وخدمة إن كان دائماً / غير مراقب / متكرّراً، ومهمّة بأعلى الصلاحيّات إن كانت وظيفة نمطيّة قصيرة، وCOM مرفوع إن كان بافتراض COM قائم.
    q1{"طبيعة تشغيل المسؤول"}
    q1 -->|"أحياناً فقط"| m1["helper EXE (Broker Model)"]
    q1 -->|"دائماً / غير مراقب / متكرّر"| m2["خدمة"]
    m1 --> m3["إن كانت وظيفة نمطيّة قصيرة فمهمّة بأعلى الصلاحيّات"]
    m2 --> m4["إن كان بافتراض COM قائم فـ COM مرفوع"]

الشكل 20: نماذج الفصل أربعة، وتُختار بتواتر تشغيل المسؤول وشكله.

7.3 صحّح موضع بيانات وقت التشغيل

مبدأ موضع الحفظ بسيط جدّاً.

• بيانات خاصّة بالمستخدم في HKCU أو %AppData%
• ذاكرة مؤقّتة محلّيّة فقط في %LocalAppData%
• بيانات مشتركة تتغيّر وقت التشغيل في %ProgramData% + ACL
• ملفّ التشغيل نفسه في Program Files

Microsoft Learn أيضاً تقول إن التطبيق ينبغي أن يحفظ في per-user location أو في %alluserprofile% (الماهيّة ProgramData) مع ضبط ACL صحيحاً.⁷

بهذا الترتيب يسهل جعل المثبِّت وحده مرفوعاً، والتطبيق قيد التشغيل بلا رفع.

flowchart TB
    accTitle: تصحيح الموضع يضيّق الرفع
    accDescr: مخطّط يبيّن أن الترتيب بمبدأ بيانات خاصّة بالمستخدم إلى HKCU أو AppData، وذاكرة مؤقّتة محلّيّة إلى LocalAppData، وبيانات مشتركة تتغيّر وقت التشغيل إلى ProgramData وACL، وملفّ التشغيل نفسه إلى Program Files، يسهّل جعل المثبِّت وحده مرفوعاً والتطبيق قيد التشغيل بلا رفع.
    p1["رتّب موضع بيانات وقت التشغيل وفق المبدأ"] --> p2["ما يحتاج الرفع يصير وضع ملفّ التشغيل فقط"]
    p2 --> p3["المثبِّت وحده يُرفَع"]
    p2 --> p4["التطبيق قيد التشغيل بلا رفع"]

الشكل 21: ترتيب الموضع أساس لحصر الرفع في لحظة التثبيت.

7.4 قرّر per-user وper-machine أوّلاً

هنا ما يسهل تفويته أكثر ممّا يُظنّ.

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

إن بقي هذا الحكم غامضاً يسهل لاحقاً الاختلاط:

• التثبيت وحده بمسؤول
• التشغيل أيضاً بمسؤول
• التحديث أيضاً بمسؤول
• جزء فقط في user context

فرق per-user / per-machine ليس حديث طريقة توزيع فحسب، بل تصميم الصلاحيّات نفسه.

flowchart TB
    accTitle: قرّر per-user / per-machine أوّلاً
    accDescr: مخطّط يبيّن أن عدم تقرير أوّلاً إن كان كل مستخدم يدخل بنفسه أو يُدخَل في موضع واحد مشترك لجميع المستخدمين ومن يتحمّل التحديث يسهّل تفرّق صلاحيّات التثبيت والتشغيل والتحديث، وأن فرق per-user وper-machine تصميم صلاحيّات لا طريقة توزيع.
    d1["قرّر per-user / per-machine أوّلاً"] -->|"إن قرّرت"| d2["تتّسق صلاحيّات التثبيت والتشغيل والتحديث"]
    d1 -.->|"إن تقدّمت غامضاً"| d3["يختلط جزء بمسؤول وجزء في user context"]
    d2 --> d4["تصميم صلاحيّات لا طريقة توزيع"]

الشكل 22: حكم per-user / per-machine تصميم صلاحيّات يُقرَّر أوّلاً.

8. إلى أيّ جهة يتّجه Windows القادم

حتى مارس 2026 توجد في Windows 11 وظيفة Administrator protection (preview). Microsoft Learn توضّح هذه الوظيفة بأنّها تحافظ عادة على deprivileged state، وتعطي admin rights just-in-time عند الحاجة فقط.⁵

علاوة على ذلك توضّح Microsoft أنّها تطلب مصادقة صريحة قبل عمليات تحتاج امتياز المسؤول مثل تثبيت البرمجيّات، وتغيير إعدادات النظام مثل الوقت أو السجلّ، والوصول إلى بيانات حسّاسة.⁵

الوظيفة نفسها ما زالت preview، والنشر العام أيضاً مرحلي.⁵

هنا نريد أيضاً تثبيت المعنى العملي لكونها preview. الوظيفة التي تحمل وسم preview قد يتغيّر سلوكها أو بنود إعدادها حتى التوفير العام، وقد لا يمكن تفعيلها في كلّ بيئة أصلاً. لذلك أأمن تجنّب استخدام من هذا النوع في الوقت الحالي.

• النشر على الشركة كلّها كتكوين قياسي للإنتاج
• إسقاط تصميم الرفع في جانب التطبيق بافتراض أن هذه الوظيفة مفعّلة
• جعل هذه الوظيفة إلزاميّة كمتطلّب تشغيل في بيئة العميل

الموضع الواقعي هو تأكيد السلوك في بيئة اختبار، ومواءمة التصميم وحده بافتراض «الميل إلى هنا مستقبلاً». بالمقابل، إن جعلت الآن asInvoker أساساً وقلّلت الرفع، فلن تضطر عند التوفير العام لهذه الوظيفة.

flowchart TB
    accTitle: الموضع الواقعي تجاه وظيفة preview
    accDescr: مخطّط يبيّن أن الوظيفة بوسم preview قد يتغيّر سلوكها أو إعدادها حتى التوفير العام، لذا يُتجنَّب النشر كتكوين قياسي للإنتاج أو إسقاط تصميم الرفع بافتراض التفعيل أو جعلها متطلّباً في بيئة العميل، والواقعي تأكيد السلوك في بيئة اختبار ومواءمة التصميم وحده بافتراض الميل إلى هنا مستقبلاً.
    p1["Administrator protection ما زال preview"] -.-> p2["تجنّب النشر كتكوين قياسي للإنتاج أو جعله متطلّباً إلزاميّاً"]
    p1 --> p3["أكّد السلوك في بيئة اختبار"]
    p3 --> p4["واءم التصميم وحده بافتراض الميل إلى هنا مستقبلاً"]
    p4 --> p5["الأساس asInvoker وتقليل الرفع يجنّبان الاضطرار"]

الشكل 23: لا تُجعَل وظيفة preview افتراضاً؛واءم اتجاه التصميم وحده.

لكن الاتجاه واضح جدّاً.

• عدم الإبقاء على رمز المسؤول طوال الوقت
• الرفع في اللحظة المطلوبة فقط
• فصل الجلسة المرفوعة
• زيادة وضوح «متى وأيّ تطبيق ولماذا صار مسؤولاً»

أي يجوز رؤية أن تصميم «تشغيل الكلّ بمسؤول على أيّ حال» سيسوء توافقه أكثر فأكثر.

flowchart TB
    accTitle: الجهة التي يتّجه إليها Windows
    accDescr: مخطّط يبيّن أن Windows يميل إلى عدم الإبقاء على رمز المسؤول طوال الوقت، والرفع في اللحظة المطلوبة فقط، وفصل الجلسة المرفوعة، وزيادة وضوح متى وأيّ تطبيق ولماذا صار مسؤولاً، وأن تصميم تشغيل الكلّ بمسؤول على أيّ حال سيسوء توافقه.
    w1["عدم الإبقاء على رمز المسؤول طوال الوقت"] --> w2["الرفع في اللحظة المطلوبة فقط"]
    w2 --> w3["فصل الجلسة المرفوعة"]
    w3 --> w4["زيادة وضوح متى وأيّ تطبيق ولماذا صار مسؤولاً"]
    w4 -.-> w5["تصميم تشغيل الكلّ بمسؤول يسوء توافقه"]

الشكل 24: الاتجاه واضح، والرفع يميل إلى «اللحظة المطلوبة فقط وبشكل صريح».

9. سوء فهم شائع

9.1 «أنا مستخدم مسؤول، لذا لا ينبغي أن يظهر UAC»

يظهر. عند تفعيل UAC تعمل العمليّات العاديّة حتى لعضو مجموعة Administrators بلا رفع، ولا يحدث الرفع إلا عند الحاجة.⁶²

9.2 «التثبيت يحتاج المسؤول دائماً»

ليس دائماً. مثل تثبيت per-user إلى %LocalAppData%، هناك تصميم يوزَّع بلا امتياز مسؤول.¹¹¹²

9.3 «لأنّه يُوضَع في Program Files، يجوز حفظ الإعداد هناك أيضاً»

لا يجوز. موضع وضع ملفّ التشغيل وموضع حفظ البيانات التي تتغيّر وقت التشغيل ينبغي فصلهما. Microsoft أيضاً تذكر الكتابة وقت التشغيل إلى Program Files أو HKLM كمثال نموذجي للرفع غير اللازم.⁴⁷

9.4 «التشغيل كمسؤول وحده يحلّ كلّ مشكلة تصميم»

لا يحلّ. قد يعمل مؤقّتاً، لكن سطح الهجوم وقابلية التشغيل والتوزيع وسهولة الدعم يسهل أن تسوء. علاوة على ذلك لا يمكن رفع جزء فقط داخل العمليّة نفسها حسب الملاءمة.²¹⁴

9.5 «كان يعمل قديماً، إذن هو صحيح الآن أيضاً»

ليس بالضرورة. إن كان تطبيق 32 بت قديم «يعمل مصادفة» بالافتراضيّة فقط، يظهر المشكلة بالتحويل إلى 64 بت أو إضافة بيان. الافتراضيّة إجراء مؤقّت للتوافق لا حلّ طويل الأجل.³⁷

10. الخلاصة

لزوم امتياز المسؤول على Windows، إن قيل بجملة، يُحسَم بـ «إلى أين تذهب لتغيّر ماذا».

• تغيير من أجلك أنت يسهل اكتماله بمستخدم قياسي
• تغيير لجميع المستخدمين أو الجهاز ككلّ يسهل لزوم المسؤول
• لمس منطقة محميّة في نظام التشغيل أو حدّ أمان يلزم امتياز المسؤول

وما يهمّ حقّاً في الممارسة هو فصل المعالجة التي تحتاج امتياز المسؤول حقّاً عن المعالجة التي صارت تحتاج المسؤول لمجرّد مقتضى موضع الحفظ.

في تطوير تطبيقات Windows خصوصاً هذا الخطّ نافع جدّاً.

• اجعل الـ UI بلا رفع أساساً
• اقطع معالجة المسؤول إلى EXE آخر / خدمة / مهمّة
• قرِّب بيانات وقت التشغيل إلى جانب AppData / HKCU / ProgramData
• قرّر per-user / per-machine أوّلاً

flowchart TB
    accTitle: خطوط نافعة في تطوير تطبيقات Windows
    accDescr: مخطّط يبيّن خطوطاً نافعة في الممارسة: جعل الـ UI بلا رفع أساساً، وقطع معالجة المسؤول إلى EXE آخر أو خدمة أو مهمّة، وتقريب بيانات وقت التشغيل إلى جانب AppData أو HKCU أو ProgramData، وتقرير per-user أو per-machine أوّلاً.
    g1["اجعل الـ UI بلا رفع أساساً"] --> g2["اقطع معالجة المسؤول إلى EXE آخر / خدمة / مهمّة"]
    g2 --> g3["قرِّب بيانات وقت التشغيل إلى AppData / HKCU / ProgramData"]
    g3 --> g4["قرّر per-user / per-machine أوّلاً"]

الشكل 25: رسم هذه الخطوط الأربعة أوّلاً يحسّن رؤية UAC والتوزيع والتصميم.

«هل يلزم امتياز المسؤول» ليس حديث كون التطبيق فخماً. بل حديث أيّ حدّ في نظام التشغيل يلمسه.

امتلاك هذه الرؤية أوّلاً يحسّن كثيراً رؤية سلوك UAC واختيار طريقة التثبيت وتصميم التطبيق.

11. مقالات ذات صلة

• كيف تعزل العمل الذي يحتاج إلى المسؤول فقط داخل تطبيقات Windows
• قائمة تحقّق للحدّ الأدنى من الأمان في تطوير تطبيقات Windows
• كيف تختار نموذج توزيع تطبيق Windows - MSI و MSIX و ClickOnce و xcopy والـ custom updaters

روابط مرجعية

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

لماذا يظهر «العملية المطلوبة تحتاج امتياز المسؤول»؟

لأن التطبيق يحاول لمس حدّ يؤثّر على نظام التشغيل أو الجهاز ككلّ. نموذجيّاً الكتابة إلى منطقة محميّة مثل Program Files أو Windows أو System32 أو HKLM، وتسجيل خدمة Windows أو تغيير تكوينها، وإدخال برنامج تشغيل للنواة، وتغيير قواعد الجدار الناري. كذلك يُطلَب الرفع إذا أعلن البيان requireAdministrator، أو إذا احتوى اسم الملفّ على install / setup / update فوقع في installer detection في Windows. كثيراً ما يحدث لا لأن المعالجة متقدّمة، بل لأن موضع حفظ الإعداد أو السجلّ صار منطقة محميّة.

لماذا يظهر UAC رغم أن الحساب مسؤول؟

لأن العمليّات التي يطلقها عضو مجموعة Administrators، عند تفعيل UAC، تعمل بصلاحيّات مستخدم قياسي ما لم تُرفَع خصوصاً. حساب Windows لديك مسؤول، لكن التطبيق الذي أطلقته الآن يعمل بلا رفع، وظهور UAC فقط لحظة العملية التي تحتاج امتياز المسؤول سلوك طبيعي جدّاً على Windows. انتماء المستخدم إلى مجموعة Administrators وكون التطبيق يعمل الآن برمز وصول مسؤول حديثان منفصلان.

هل تثبيت التطبيق يحتاج دائماً صلاحيات المسؤول؟

ليس دائماً. تثبيت per-user يضع التطبيق تحت %LocalAppData% يمكن تصميمه للتوزيع والتحديث بلا امتياز مسؤول. مثلاً تثبيت per-user لعميل Remote Desktop يدخل تحت LocalAppData في ملفّ تعريف كل مستخدم ويُحدَّث بلا صلاحيات مسؤول، وOneDrive أيضاً تثبيت per-user افتراضيّاً. ما يسهل أن يحتاج المسؤول هو التثبيت لكل المستخدمين (per-machine) الذي يكتب إلى Program Files أو HKLM. per-user أو per-machine ليس حديث طريقة توزيع بل تصميم الصلاحيّات نفسه، فينبغي تقريره أوّلاً.

هل يمكن تشغيل بعض معالجة التطبيق فقط بصلاحيات المسؤول؟

لا يمكن داخل العمليّة نفسها «جعل بعض الدوال مسؤولة فقط لحظة ضغط هذا الزرّ». UAC حديث الرمز الذي تعمل به العمليّة، والعمليّات الابن ترث الرمز. إن لزم فافصل إلى وحدة تشغيل أخرى. النماذج النموذجيّة أربعة: Administrator Broker Model الذي يجمع UI مستخدم قياسي مع helper EXE للمسؤول، وOperating System Service Model الذي يستخدم خدمة مقيمة، وElevated Task Model الذي يستخدم مهمّة مجدولة بأعلى الصلاحيّات، وAdministrator COM Object Model الذي يستخدم COM مرفوعاً.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

يركّز على تطوير برامج ويندوز، والاستشارات التقنية، والتحقيق في الأخطاء، ويتميّز في المشاريع التي تبقى فيها الأصول القديمة ناشطة، وفي تشخيص الأعطال التي يصعب تحديد سببها.