c# - System.UnauthorizedAccessException أثناء تشغيل.exe ضمن ملفات البرنامج




windows wix (2)

من خلال مثبت WiX ، قمت بتثبيت تطبيق Windows الخاص بي والمجلد قيد الإنشاء ضمن c:\ProgramFiles مع .exe والمطلوب dll.

أثناء تشغيل .exe ، أحصل على System.UnauthorizedAccessException .

واسمحوا لي أن أعرف إذا كان هناك أي اقتراحات مفيدة.

يرجى الاطلاع على سجل الأحداث أدناه كمرجع.

Application: xxxxxxx.exe
Framework Version: v1.0.0
Description: The process was terminated due to an unhandled exception.
Exception Info: System.UnauthorizedAccessException
   at System.IO.__Error.WinIOError(Int32, System.String)
   at System.IO.FileStream.Init(System.String, System.IO.FileMode, System.IO.FileAccess, Int32, Boolean, System.IO.FileShare, Int32, System.IO.FileOptions, SECURITY_ATTRIBUTES, System.String, Boolean, Boolean, Boolean)
   at System.IO.FileStream..ctor(System.String, System.IO.FileMode, System.IO.FileAccess, System.IO.FileShare, Int32, System.IO.FileOptions, System.String, Boolean, Boolean, Boolean)
   at System.IO.StreamWriter.CreateFile(System.String, Boolean, Boolean)
   at System.IO.StreamWriter..ctor(System.String, Boolean, System.Text.Encoding, Int32, Boolean)
   at System.IO.StreamWriter..ctor(System.String, Boolean)
   at System.IO.File.AppendText(System.String)

سبب

هذا يبدو وكأنه انتهاك وصول بسيط - تحاول الحصول على حق الوصول للكتابة إلى ملف ليس لديك أذونات له - في السياق الذي تقوم بتشغيله (الملفات الموجودة تحت %ProgramFiles% غير قابلة للكتابة للمستخدمين العاديين أو المسؤولين غير المرتبطين - باستثناء المحاكاة الافتراضية للملفات ، انظر القسم 9 أدناه).

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

الحلول الممكنة المقترحة

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

القائمة أدناه ليست بالترتيب المفضل . في الواقع ، النهج رقم 1 غير مرغوب فيه للغاية في رأيي. يمكن أن يكون النهج 6 فعالًا ، لكن ليس كبيرًا (بالتأكيد أفضل من 1 ). يمكنني التعايش مع الأساليب الأخرى (باستثناء 9 ) ، وربما تكون الطريقة 2 الأكثر شيوعًا في الاستخدام.

1. رفع التطبيق (حقوق المسؤول) : كما اقترح آخرون ، يمكنك تشغيل التطبيق الخاص بك مع حقوق المسؤول (ممارسة سيئة للغاية هذه الأيام - حقوق المسؤول منتشرة ، مفاتيح المدينة ، وجعل تطبيقك هدفًا للتسلل ، كما يجعل تطبيق أكثر خطورة إذا كان يحتوي على أخطاء من العيار). في ما يلي نبذة مختصرة: كيف يمكنني فرض تطبيق .NET على العمل كمسؤول؟ .

  • المستخدمون المسؤولون فقط : بشكل حاسم ، لن يعمل الارتفاع للمستخدمين العاديين! (سوف تتم مطالبتك بكلمة مرور مسؤول). يمكن للمسؤولين فقط رفع !
  • كلمة مرور المسؤول الفارغة : إذا كانت هناك كلمة مرور مسؤول فارغة في المربع (شائعة على أجهزة الكمبيوتر المنزلية) ، فيمكن لأي مستخدم رفع أي مجموعة ثنائية للارتقاء إلى حقوق المسؤول حسب الرغبة (باستخدام حساب كلمة مرور فارغة) - أثناء تسجيل الدخول إلى حساب مقيد خاص به (من الواضح أنه يمكنهم أيضًا تسجيل الدخول بالفعل كمسؤول باستخدام حساب كلمة المرور الفارغة وإطلاق أي شيء تمامًا - لذا فجوة الأمان موجودة بالفعل بكلمة مرور فارغة بصرف النظر عن مشكلات الارتفاع - ولكن لماذا تسمح بالرفع باستخدام حسابات كلمة مرور فارغة؟ ).
  • UAC : ماذا يحدث عندما يتم تعطيل UAC؟ ربما لم تتم مطالبة المستخدمين العاديين بكلمة مرور ، وفشل الإطلاق؟ لم تتح لي الفرصة لمحاولة حتى الآن.
  • الأمان : في بعض السيناريوهات ، يبدو أن العمليات المرتفعة تكون قادرة على إطلاق العمليات المرتفعة الأخرى التي يمكن أن تدوم العملية الأصلية (تعتمد على إطلاق امتيازات المستخدم NT). جنون.

2. ملف تعريف المستخدم (نقل الملف) : يمكنك تحديد الملف الذي يسبب انتهاك الوصول (نوع من ملفات الإعدادات؟) ونقله إلى موقع يتمتع المستخدمون فيه بحقوق وصول منتظمة في جميع الحالات. عموما في مكان ما في ملف تعريف المستخدم (مستحسن).

3. وصول للقراءة فقط : في كثير من الأحيان يمكنك الحصول على وصول للقراءة فقط لملفات الإعدادات. ربما يمكنك تطبيق هذا النهج بدلاً من ذلك؟ كل هذا يتوقف على تصميم التطبيق الخاص بك. ربما يمكنك handle the access denied exception ثم قم بتشغيل للقراءة فقط؟

4. الافتراضات الداخلية : كنكهة للنهج للقراءة فقط ، يمكنك فقدان ملف الإعدادات بالكامل والاعتماد على الإعدادات الافتراضية الداخلية. نادرا ما خيار أعتقد ، ولكن ممكن.

5. الإعدادات عبر الإنترنت؟ : بعض الأشخاص يحبون إزالة ملفات الإعدادات تمامًا (أو جعلها للقراءة فقط) ثم يسترجعون "الإعدادات الحقيقية" من قاعدة بيانات عند التشغيل. يمكن أن يكون لهذا النهج مزايا كبيرة - خاصة بالنسبة لتطبيقات الشركات - إعدادات الإدارة وإصدارها ، والقضاء على مشكلات تجوال ملف تعريف المستخدم ، وما إلى ذلك ... (والتحديات بالطبع - network issues ، firewall ، proxy ، etc... ).

6. إذن ACL : يمكنك تطبيق أذونات ACL على الملف المعني عند التثبيت ، مما يتيح للمستخدمين العاديين الكتابة إليه. ليس تصميم رائع على الإطلاق ، لكنه سيعمل . وبالتأكيد أفضل من العمل باستخدام حقوق المسؤول (مرتفعة) - لأنك تحدد الوصول المطلوب ، ولا ترفع العملية برمتها. لا تقم فقط بتسوية الوصول الكامل إلى المجلد بالكامل - فقط الوصول المفتوح للكتابة للملفات الفردية.

7. خدمة Windows : في بعض الحالات ، يمكن تشغيل أجزاء التطبيق التي تتطلب حقوق مرتفعة كخدمة Windows. ليس هذا النهج الذي رأيته كثيرًا ، لكن ممكن. بعد ذلك ، تقوم بتثبيت الخدمة لتشغيلها كـ LocalSystem أو حساب مكافئ ، مرتفع ( أو باستخدام حسابات الخدمة - راجع قسم " الطرق الأخرى " - أو هذه الإجابة البديلة ). ربما يمكنني ذكر scheduled task أيضًا - لم أحاول مطلقًا استخدام مهمة مجدولة لمثل هذا السيناريو.

8. انتحال شخصية : أفترض أنه يمكنك انتحال شخصية حساب له حقوق وصول للكتابة إلى الموقع المعني. لا أستخدم هذا النهج لذا لست متأكدًا من التفاصيل الفنية والجوانب والتحديات. مجرد الطباشير عنه كخيار.

9. النهج الافتراضية : فقط ذكر هذا. أشكال مختلفة من المحاكاة الافتراضية - على سبيل المثال السياسات التي يمكنك تمكينها للسماح بإعادة توجيه إخفاقات كتابة الملفات والسجلات إلى موقع قابل للكتابة (بشكل أكبر على غرار إعادة توجيه البيانات - مع كل الالتباس الذي يترتب على ذلك - هذا ليس حلاً - في الحقيقة تنوي Microsoft لإزالة الميزة في إصدار Windows في المستقبل. غير متأكد من الحالة في نظام التشغيل Windows 10. MSDN على "المحاكاة الافتراضية للتسجيل" . عموما لا توجد مشاكل حلها ، ولكن عدة مشاكل غير معترف بها. من المؤكد عمومًا أن تتسبب في حدوث تشويش حيث لا يرى الأشخاص مكان كتابة البيانات ، ولا تتم مشاركة البيانات بين المستخدمين - ولكن خاصة بالمستخدمين. وهناك دفق كامل للبيانات الافتراضية / دفق البيانات مثل App-V والحاويات التي تتيح الوصول الكامل. ليس تخصصي ، وليس تفضيلي.

يرجى عدم استخدام هذا المحاكاة الافتراضية أو هراء إعادة توجيه البيانات (لأنه لا يمكن أن تتعطل التطبيقات القديمة ، وليس للتطبيقات الجديدة لاستخدام). ما زلت سأضيف رابطًا لبعض التفاصيل الفنية لكيفية عمل الميزة فعليًا (هناك عدد من المتطلبات المسبقة التي يجب الوفاء بها قبل إعادة التوجيه): ملف سجل log4net غير مرئي في مستكشف Windows في المجلد الفرعي لتثبيت التطبيق ( recommended to show why this feature should never be used بإظهاره recommended to show why this feature should never be used )

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

قد تكون قراءة متورطة ، ولكن هنا - توفر بشكل أساسي بعض التباينات الإضافية للاحتمالات المذكورة أعلاه :

بعض الروابط :


لا تحاول الكتابة حيث يجب ألا تكتب التطبيقات. استخدم مجلدات أخرى مثل:

Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)

إذا لم يكن هناك بديل ممكن ، وأشك بجدية في تشغيل الملف القابل للتنفيذ بامتيازات إدارية.

https://msdn.microsoft.com/en-us/library/bb756929.aspx





windows-installer