الخلاصة

  • تتكون ACL لصندوق IMAP من أزواج بين معرّف وحقوق. وقد يطابق المستخدم اسمه الشخصي ومجموعات عدة وanyone معاً، فيبقى كل سطر مدخلاً للحساب لا حكمه النهائي.
  • يعرض GETACL القواعد المسجلة، ويعرض LISTRIGHTS ما يستطيع الخادم منحه لمعرّف، أما MYRIGHTS فيعيد النتيجة الفعلية للجلسة المتصلة.
  • يحذف DELETEACL زوجاً واحداً، بينما يطرح المعرّف السلبي حقاً أثناء التقييم. أوضح RFC 4314 الفرق من دون فرض نموذج هوية محلي واحد على كل الخوادم.

انتهى التعديل قبل أن ينتهي النفاذ

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

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

جعل RFC 1730 صندوق البريد البعيد كائناً قابلاً للتشغيل عبر الشبكة. يختار العميل المجلدات، ويقرأ الرسائل، ويغير العلامات والحالة المحفوظة على الخادم. وعندما يتشارك عدة أشخاص الكائن نفسه، لا تكفي صلاحيات محلية مخفية داخل نظام الملفات؛ يحتاج العميل البعيد إلى سؤال الجهة التي ستنفذ أمره التالي.

في يناير 1997 أضاف RFC 2086، ضمن Standards Track، القدرة ACL. عرّف قائمة الصندوق مجموعة من أزواج <المعرّف، الحقوق>. وصار العميل قادراً على قراءتها وتعديلها من دون الحصول على قاعدة الحسابات والمجموعات كاملة.

دخلت الجلسة الواحدة بأكثر من اسم

حُجز anyone للهوية العامة، بما فيها الاتصال المجهول. ومثّلت الأسماء التي يقبلها LOGIN أو AUTHENTICATE مستخدميها. أما السلاسل الأخرى فيمكن أن تعني مجموعات أو فئات يحددها التنفيذ.

لهذا قد يطابق فريد fred وsupport-team وanyone في اللحظة نفسها. لم يفرض RFC عملية دمج عالمية. يستطيع خادم جمع حقوق كل المعرّفات المنطبقة، ويستطيع آخر اعتماد المعرّف الأكثر تحديداً وحده.

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

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

ثلاث أسئلة لثلاث طبقات

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

ويبين LISTRIGHTS الحقوق التي يمكن منحها لمعرّف معين. إذا كان النظام المحلي لا يفصل بعض العمليات، يعرض الرد الحقوق الإلزامية والمجموعات المرتبطة التي تمنح معاً. إنه وصف لما يستطيع نموذج الخادم التعبير عنه، لا لما يملكه المستخدم الآن.

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

إعادة قراءة ACL، ونتيجة MYRIGHTS، وقبول عملية محمية أدلة مختلفة. قد ينجح حفظ القاعدة من دون أن تتغير الصلاحية، وقد تتغير صلاحية جلسة جديدة بينما تحتفظ أخرى بالقديمة، ولا يحول نجاح الأمر بيانات الاعتماد إلى هوية بشرية مثبتة.

حذف سبب أم طرح حق

يزيل DELETEACL mailbox fred زوج فريد. فإذا بقي w آتياً من مجموعة أو من anyone، يكون الأمر قد نفذ عقده بدقة وتظل الكتابة متاحة.

حجز RFC 2086 المعرّفات التي تبدأ بشرطة للحقوق السلبية. وفصّل RFC 4314 المعنى: يؤدي إدخال -fred مع w إلى طرح حق الكتابة من فريد، حتى إن كان معرّف آخر مطابق سيمنحه الحق. يدخل القيد السلبي في الحساب؛ أما DELETEACL فلا يفعل سوى إزالة قطعة واحدة.

لم يكن دعم المعرّفات السلبية إلزامياً. لذلك لا يستطيع العميل أن يعد بزر عالمي من نوع «المنع يغلب السماح». عليه أن يكتشف قدرة الخادم ثم يعيد فحص النتيجة الفعلية.

وللشرطة موضعان مختلفان. تعني -w في حجة الحقوق لأمر SETACL إزالة w من الزوج المختار. أما -fred في موضع المعرّف فيمثل مدخلاً سلبياً في التقييم. الأول تحرير لسطر؛ والثاني قد يبطل مساراً موروثاً. تشابه العلامة لا يساوي تشابه السلطة.

تفصيل السلطة مع إبقاء جسر إلى العملاء القدماء

مثلت النسخة الأولى بأحرف حقوق الظهور والقراءة وحالة المشاهدة والعلامات الأخرى والإدراج والنشر والإنشاء والحذف والإدارة. لكن c وd كانا أوسع من اللازم؛ فوسم رسالة للحذف، ومحوها نهائياً، وحذف الصندوق كله أفعال مختلفة.

حل RFC 4314 محل RFC 2086 في ديسمبر 2005. صار k لإنشاء الصناديق التابعة، وx لحذف الصندوق أو نقله، وt لوضع علامة الحذف على الرسالة، وe لمحو الرسائل. وبقي c وd حقين افتراضيين للتوافق. ينفذ الخادم الجديد التقسيم الدقيق، ويعيد إلى العميل القديم إسقاطاً خشناً لكنه محدد.

أعلنت القدرة RIGHTS= الحقوق الإضافية. وإذا كانت البنية المحلية لا تمنح عدة حقوق إلا معاً، أظهر LISTRIGHTS الارتباط. لم يدّع العقد المشترك أن كل خادم يملك الحبيبات نفسها.

وطُلب من العميل القادر على قراءة ACL وتعديلها أن يحافظ على الحقوق التي لا يفهمها ولا يسمح للمستخدم بتحريرها. وإلا قرأ برنامج قديم قيداً حديثاً، ثم كتب الأحرف التي يعرفها فقط فمحا إذناً جديداً بصمت. صار احترام المجهول شرطاً للتوسع.

كان للسحب حد زمني أيضاً

سمح RFC 4314 للخادم بتخزين الحقوق عند اختيار الصندوق. بعد SETACL أو DELETEACL قد تواصل جلسة سبق أن اختارت الصندوق تنفيذ STORE أو EXPUNGE بالحساب القديم حتى تعيد الاختيار.

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

وفي الاتصال الواحد أمكن ضبط الترتيب. إذا أرسل العميل SETACL ثم MYRIGHTS في pipeline، وجب إكمال التعديل قبل حساب الرد الثاني. لا تكشف هذه الضمانة ما تحتفظ به جلسة أخرى.

قائمة السلطة نفسها معلومة حساسة

قد تكشف ACL وجود الصندوق وأسماء الحسابات والمجموعات والمسؤولين. حذر RFC 2086 من أن يفشي GETACL غير المصرح له صندوقاً مقيداً. واشترط RFC 4314 أن يبدو الرد، عند غياب حق الظهور، مثل الرد على صندوق غير موجود.

كما لم يعد حق قراءة الرسائل كافياً تلقائياً لرؤية ACL، لأن خريطة المعرّفات معلومة أمنية مستقلة. ولا تشفّر إضافة ACL هذه المعلومة بذاتها. فمن دون STARTTLS أو حماية خصوصية متفق عليها أثناء المصادقة أو طبقة أخرى، تنتقل البيانات واضحة.

صحة قرار الإذن وسرية الطريق الذي يحمل القرار مسؤوليتان منفصلتان.

أعلن المعيار ما بقي محلياً

ذكر RFC 4314 عيوبه المعروفة. ظلت طريقة دمج الحقوق من اختصاص التنفيذ، واشترك المستخدمون والمجموعات والمعرّفات الخاصة في فضاء أسماء واحد، وصَعُب بناء واجهة عامة تشرح كل نموذج، وغابت عمليات ملكية كاملة كالتي في أنظمة الملفات.

ومع ذلك عُدّ التحديث المتوافق مفيداً لأن RFC 2086 كان منشوراً في تطبيقات متعددة. عرّف RFC 9051 لاحقاً IMAP4rev2 وأبقى إضافات IMAP4rev1 المسجلة صالحة عموماً ما لم ينص غير ذلك. هذه استمرارية للعقد، لا دليل على أن كل خدمة حديثة تطبق ACL أو الحقوق السلبية.

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

المصادر