فهم قوائم التحكم بالوصول NFSv4.x في Azure NetApp Files

2025-02-13

يمكن أن يوفر بروتوكول NFSv4.x التحكم في الوصول في شكل قوائم التحكم في الوصول (ACLs)، والتي تشبه من الناحية المفاهيمية قوائم التحكم في الوصول المستخدمة في SMB عبر أذونات Windows NTFS. يتكون NFSv4.x ACL من إدخالات التحكم بالوصول الفردية (ACEs)، كل منها يوفر توجيه التحكم في الوصول إلى الخادم.

يتم إنشاء كل NFSv4.x ACL بتنسيق type:flags:principal:permissions.

النوع - نوع قائمة التحكم بالوصول التي يتم تعريفها. تتضمن الخيارات الصالحة الوصول (A)، الرفض (D)، التدقيق (U)، المنبه (L). تدعم Azure NetApp Files أنواع الوصول والرفض والتدقيق ل ACL، ولكن قوائم التحكم في الوصول للتدقيق، مع إمكانية تعيينها، لا تنتج حاليا سجلات تدقيق.
العلامات – يضيف سياقا إضافيا ل ACL. هناك ثلاثة أنواع من علامات ACE: المجموعة والتوارث والإداري. لمزيد من المعلومات حول العلامات، راجع علامات NFSv4.x ACE.
الأساسي - يحدد المستخدم أو المجموعة التي يتم تعيينها ل ACL. يستخدم أساس على NFSv4.x ACL تنسيق name@ID-DOMAIN-STRING.COM. لمزيد من المعلومات التفصيلية حول الأساسيات، راجع كيانات المستخدم والمجموعة NFSv4.x.
الأذونات - حيث يتم تعريف مستوى الوصول للمدير. يعين كل إذن حرفا واحدا (على سبيل المثال، تحصل القراءة على "r"، وتحصل الكتابة على "w" وهكذا). سيتضمن الوصول الكامل كل خطاب إذن متاح. لمزيد من المعلومات، راجع أذونات NFSv4.x.

A:g:group1@contoso.com:rwatTnNcCy هو مثال على قائمة التحكم بالوصول (ACL) صالحة، باتباع type:flags:principal:permissions التنسيق. يمنح مثال ACL حق الوصول الكامل إلى المجموعة group1 في مجال معرف contoso.com.

علامات NFSv4.x ACE

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

يمكن استخدام علامات أخرى للتحكم في ACEs، مثل التوريث والعلامات الإدارية.

علامات الوصول والرفض

تستخدم علامات الوصول (A) والرفض (D) للتحكم في أنواع الأمان ACE. يتحكم ACE للوصول في مستوى أذونات الوصول على ملف أو مجلد لمدير. يمنع رفض ACE صراحة كيانا من الوصول إلى ملف أو مجلد، حتى إذا تم تعيين الوصول إلى ACE الذي يسمح لهذا الأساسي بالوصول إلى الكائن. رفض ACEs دائما إبطال الوصول ACEs. بشكل عام، تجنب استخدام رفض ACEs، حيث تتبع NFSv4.x ACLs نموذج "الرفض الافتراضي"، مما يعني أنه إذا لم تتم إضافة قائمة التحكم بالوصول، فإن الرفض ضمني. يمكن أن يؤدي رفض ACEs إلى حدوث مضاعفات غير ضرورية في إدارة ACL.

علامات التوريث

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

يصف الجدول التالي علامات التوريث المتوفرة وسلوكياتها.

علامة التوريث	سلوك
d	- ترث الدلائل الموجودة أسفل الدليل الأصل قائمة التحكم بالوصول (ACL) - علامة التوريث موروثة أيضا
الجمعة	- ترث الملفات الموجودة أسفل الدليل الأصل قائمة التحكم بالوصول (ACL) - الملفات لا تعين علامة التوريث
أنا	وراثة فقط؛ لا ينطبق ACL على الدليل الحالي ولكن يجب تطبيق التوريث على الكائنات الموجودة أسفل الدليل
n	- عدم نشر التوريث بعد توريث قائمة التحكم بالوصول، يتم مسح علامات الوراثة على الكائنات الموجودة أسفل الأصل

أمثلة على NFSv4.x ACL

في المثال التالي، هناك ثلاثة ACEs مختلفة مع علامات توريث مميزة:

يرث الدليل فقط (di)
يرث الملف فقط (fi)
وراثة كل من الملف والدليل (fdi)

# nfs4_getfacl acl-dir

# file: acl-dir/
A:di:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fdi:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

User1 لديه دليل يرث ACL فقط. في دليل فرعي تم إنشاؤه أسفل الأصل، يتم توريث ACL، ولكن في ملف أسفل الأصل، ليس كذلك.

# nfs4_getfacl acl-dir/inherit-dir

# file: acl-dir/inherit-dir
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

# nfs4_getfacl acl-dir/inherit-file

# file: acl-dir/inherit-file 
                       << ACL missing
A::user2@CONTOSO.COM:rwaxtTnNcCy
A::user3@CONTOSO.COM:rwaxtTnNcCy
A::OWNER@:rwatTnNcCy
A:g:GROUP@:rtncy
A::EVERYONE@:rtncy

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

# nfs4_getfacl acl-dir/inherit-dir

# file: acl-dir/inherit-dir
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

# nfs4_getfacl acl-dir/inherit-file

# file: acl-dir/inherit-file
A::user2@CONTOSO.COM:rwaxtTnNcCy << no flag
A::user3@CONTOSO.COM:rwaxtTnNcCy
A::OWNER@:rwatTnNcCy
A:g:GROUP@:rtncy
A::EVERYONE@:rtncy

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

# nfs4_getfacl acl-dir/inherit-dir

# file: acl-dir/inherit-dir
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

# nfs4_getfacl acl-dir/inherit-file

# file: acl-dir/inherit-file
A::user2@CONTOSO.COM:rwaxtTnNcCy
A::user3@CONTOSO.COM:rwaxtTnNcCy << no flag
A::OWNER@:rwatTnNcCy
A:g:GROUP@:rtncy
A::EVERYONE@:rtncy

عند تعيين علامة "no-propagate" (n) على ACL، يتم مسح العلامات على إنشاءات الدليل اللاحقة أسفل الأصل. في المثال التالي، user2 يحتوي على مجموعة العلامات n . ونتيجة لذلك، يمسح الدليل الفرعي علامات الوراثة لهذا الأساسي ولا ترث الكائنات التي تم إنشاؤها أسفل هذا الدليل الفرعي ACE من user2.

#  nfs4_getfacl /mnt/acl-dir

# file: /mnt/acl-dir
A:di:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fdn:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

#  nfs4_getfacl inherit-dir/

# file: inherit-dir/
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
A::user2@CONTOSO.COM:rwaDxtTnNcCy << flag cleared
A:fd:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

# mkdir subdir
# nfs4_getfacl subdir

# file: subdir
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
<< ACL not inherited
A:fd:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

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

العلامات الإدارية

العلامات الإدارية في NFSv4.x ACLs هي علامات خاصة يتم استخدامها فقط مع أنواع Audit and Alarm ACL. تحدد هذه العلامات إما محاولات الوصول إلى النجاح (S) أو الفشل (F) للإجراءات التي سيتم تنفيذها.

يعد Audit ACL هذا مثالا على ذلك، حيث user1 يتم تدقيق محاولات الوصول الفاشلة لأي مستوى أذونات: U:F:user1@contoso.com:rwatTnNcCy.

تدعم Azure NetApp Files فقط تعيين العلامات الإدارية ل Audit ACEs، ولكن ACEs لا تعمل. لا يتم دعم المنبه ACEs في Azure NetApp Files.

أساسيات المستخدم والمجموعة NFSv4.x

مع NFSv4.x ACLs، تحدد أساسيات المستخدم والمجموعة الكائنات المحددة التي يجب أن تنطبق عليها ACE. تتبع الأساسيات بشكل عام تنسيق .name@ID-DOMAIN-STRING.COM يمكن أن يكون جزء "الاسم" من كيان مستخدم أو مجموعة، ولكن يجب أن يكون هذا المستخدم أو المجموعة قابلا للحل في Azure NetApp Files عبر اتصال خادم LDAP عند تحديد مجال معرف NFSv4.x. إذا لم يكن name@domain قابلا للحل بواسطة Azure NetApp Files، فستفشل عملية ACL مع ظهور خطأ "وسيطة غير صالحة".

# nfs4_setfacl -a A::noexist@CONTOSO.COM:rwaxtTnNcCy inherit-file
Failed setxattr operation: Invalid argument

يمكنك التحقق داخل Azure NetApp Files إذا كان يمكن حل اسم باستخدام قائمة معرف مجموعة LDAP. انتقل إلى الدعم + استكشاف الأخطاء وإصلاحها ثم قائمة معرف مجموعة LDAP.

وصول المستخدم المحلي والمجموعة عبر NFSv4.x ACLs

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

على سبيل المثال،

# nfs4_setfacl -a A:fdg:3003:rwaxtTnNcCy NFSACL
# nfs4_getfacl NFSACL/
A:fdg:3003:rwaxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rwaDxtTnNcy
A::EVERYONE@:rwaDxtTnNcy

# nfs4_setfacl -a A:fdg:3003@CONTOSO.COM:rwaxtTnNcCy NFSACL
Failed setxattr operation: Invalid argument

# nfs4_setfacl -a A:fdg:users:rwaxtTnNcCy NFSACL
Failed setxattr operation: Invalid argument

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

يمكن رؤية بيانات الاعتماد التي تم تمريرها من العميل إلى الخادم عبر التقاط حزمة البيانات كما هو موضح أدناه.

المحاذير:

يعني استخدام المستخدمين المحليين والمجموعات ل ACLs أن كل عميل يصل إلى الملفات/المجلدات يجب أن يكون لديه معرفات مستخدم ومجموعة مطابقة.
عند استخدام معرف رقمي ل ACL، تثق Azure NetApp Files ضمنيا في أن الطلب الوارد صالح وأن المستخدم الذي يطلب الوصول هو من يقول إنه عضو في المجموعات التي يدعي أنه عضو فيها. يمكن تزييف هوية المستخدم أو المجموعة الرقمية إذا كان المستخدم السيئ يعرف المعرف الرقمي ويمكنه الوصول إلى الشبكة باستخدام عميل لديه القدرة على إنشاء مستخدمين ومجموعات محليا.
إذا كان المستخدم عضوا في أكثر من 16 مجموعة، رفض وصول أي مجموعة بعد المجموعة السادسة عشرة (بالترتيب الأبجدي الرقمي) إلى الملف أو المجلد، ما لم يتم استخدام دعم LDAP والمجموعة الموسعة.
يوصى بشدة باستخدام LDAP وسلاسل أسماء name@domain الكاملة عند استخدام NFSv4.x ACLs لتحسين إمكانية الإدارة والأمان. يسهل الحفاظ على مستودع المستخدم والمجموعة المدار مركزيا ويصعب تزييف هوياته، مما يجعل وصول المستخدم غير المرغوب فيه أقل احتمالا.

مجال معرف NFSv4.x

مجال المعرف هو مكون مهم من الأساسي، حيث يجب أن يتطابق مجال المعرف على كل من العميل وداخل Azure NetApp Files لأسماء المستخدمين والمجموعات (على وجه التحديد، الجذر) للظهور بشكل صحيح على ملكية الملفات/المجلدات.

يقوم Azure NetApp Files بتعيين مجال معرف NFSv4.x افتراضيا إلى إعدادات مجال DNS لوحدات التخزين. عملاء NFS أيضا افتراضيا إلى مجال DNS لمجال معرف NFSv4.x. إذا كان مجال DNS الخاص بالعميل مختلفا عن مجال Azure NetApp Files DNS، فسيحدث عدم تطابق. عند سرد أذونات الملفات باستخدام أوامر مثل ls، يظهر المستخدمون/المجموعات على أنها "لا أحد".

عند حدوث عدم تطابق مجال بين عميل NFS وAzure NetApp Files، تحقق من سجلات العميل بحثا عن أخطاء مشابهة لما يلي:

August 19 13:14:29 nfsidmap[17481]: nss_getpwnam: name 'root@microsoft.com' does not map into domain ‘CONTOSO.COM'

يمكن تجاوز مجال معرف عميل NFS باستخدام إعداد "المجال" لملف /etc/idmapd.conf. على سبيل المثال: Domain = CONTOSO.COM.

تسمح لك Azure NetApp Files أيضا بتغيير مجال معرف NFSv4.1. للحصول على تفاصيل إضافية، راجع كيفية: تكوين مجال معرف NFSv4.1 لملفات Azure NetApp.

أذونات NFSv4.x

أذونات NFSv4.x هي الطريقة للتحكم في مستوى الوصول إلى مستخدم معين أو مدير مجموعة معين في ملف أو مجلد. تسمح الأذونات في NFSv3 فقط بمستويات القراءة/الكتابة/التنفيذ (rwx) لتعريف الوصول، ولكن NFSv4.x يوفر عددا كبيرا من عناصر التحكم في الوصول الدقيقة الأخرى كتحسن على وحدات بت وضع NFSv3.

هناك 13 إذنا يمكن تعيينها للمستخدمين، و14 إذنا يمكن تعيينها للمجموعات.

رسالة إذن	تم منح الإذن
r	قراءة ملفات البيانات/القوائم والمجلدات
w	كتابة البيانات/إنشاء الملفات والمجلدات
ص	إلحاق البيانات/إنشاء الدلائل الفرعية
×	تنفيذ الملفات/اجتياز الدلائل
d	حذف الملفات/الدلائل
D	حذف الدلائل الفرعية (الدلائل فقط)
الوقت	قراءة السمات (GETATTR)
د	كتابة السمات (SETATTR/chmod)
n	قراءة السمات المسماة
N	كتابة السمات المسماة
ج	قراءة قوائم التحكم بالوصول
C	كتابة قوائم التحكم بالوصول
o	مالك الكتابة (chown)
س	إدخال/إخراج متزامن

عند تعيين أذونات الوصول، يلتزم مستخدم أو مجموعة أساسية بتلك الحقوق المعينة.

أمثلة أذونات NFSv4.x

توضح الأمثلة التالية كيفية عمل الأذونات المختلفة مع سيناريوهات التكوين المختلفة.

المستخدم الذي له حق الوصول للقراءة (r فقط)

مع الوصول للقراءة فقط، يمكن للمستخدم قراءة السمات والبيانات، ولكن يتم رفض أي وصول للكتابة (البيانات والسمات والمالك).

A::user1@CONTOSO.COM:r

sh-4.2$ ls -la
total 12
drwxr-xr-x 3 root root 4096 Jul 12 12:41 .
drwxr-xr-x 3 root root 4096 Jul 12 12:09 ..
-rw-r--r-- 1 root root    0 Jul 12 12:41 file
drwxr-xr-x 2 root root 4096 Jul 12 12:31 subdir
sh-4.2$ touch user1-file
touch: can't touch ‘user1-file’: Permission denied
sh-4.2$ chown user1 file
chown: changing ownership of ‘file’: Operation not permitted
sh-4.2$ nfs4_setfacl -e /mnt/acl-dir/inherit-dir
Failed setxattr operation: Permission denied
sh-4.2$ rm file
rm: remove write-protected regular empty file ‘file’? y
rm: can't remove ‘file’: Permission denied
sh-4.2$ cat file
Test text

المستخدم الذي له حق الوصول للقراءة (r) وسمات الكتابة (T)

في هذا المثال، يمكن تغيير الأذونات الموجودة على الملف بسبب إذن سمات الكتابة (T)، ولكن لا يمكن إنشاء أي ملفات حيث يسمح بالوصول للقراءة فقط. يوضح هذا التكوين نوع عناصر التحكم الدقيقة التي يمكن أن توفرها NFSv4.x ACLs.

A::user1@CONTOSO.COM:rT

sh-4.2$ touch user1-file
touch: can't touch ‘user1-file’: Permission denied
sh-4.2$ ls -la
total 60
drwxr-xr-x  3 root     root    4096 Jul 12 16:23 .
drwxr-xr-x 19 root     root   49152 Jul 11 09:56 ..
-rw-r--r--  1 root     root      10 Jul 12 16:22 file
drwxr-xr-x  3 root     root    4096 Jul 12 12:41 inherit-dir
-rw-r--r--  1 user1    group1     0 Jul 12 16:23 user1-file
sh-4.2$ chmod 777 user1-file
sh-4.2$ ls -la
total 60
drwxr-xr-x  3 root     root    4096 Jul 12 16:41 .
drwxr-xr-x 19 root     root   49152 Jul 11 09:56 ..
drwxr-xr-x  3 root     root    4096 Jul 12 12:41 inherit-dir
-rwxrwxrwx  1 user1    group1     0 Jul 12 16:23 user1-file
sh-4.2$ rm user1-file
rm: can't remove ‘user1-file’: Permission denied

ترجمة بتات الوضع إلى أذونات NFSv4.x ACL

عند تشغيل chmod لعنصر مع تعيين NFSv4.x ACLs، يتم تحديث سلسلة من قوائم التحكم بالوصول للنظام بأذونات جديدة. على سبيل المثال، إذا تم تعيين الأذونات إلى 755، تحديث ملفات ACL للنظام. يوضح الجدول التالي ما تترجم إليه كل قيمة رقمية في بت الوضع في أذونات NFSv4 ACL.

راجع أذونات NFSv4.x لجدول يوضح جميع الأذونات.

الوضع الرقمي بت	أذونات NFSv4.x المقابلة
1 - تنفيذ (x)	تنفيذ وقراءة السمات وقراءة قوائم التحكم في الوصول ومزامنة الإدخال/الإخراج (xtcy)
2 – كتابة (w)	الكتابة، وإلحاق البيانات، وقراءة السمات، وكتابة السمات، وكتابة السمات المسماة، وقراءة ACLs، ومزامنة الإدخال/الإخراج (watTNcy)
3 - الكتابة/التنفيذ (wx)	الكتابة، وإلحاق البيانات، والتنفيذ، وقراءة السمات، وكتابة السمات، وكتابة السمات المسماة، وقراءة ACLs، ومزامنة الإدخال/الإخراج (waxtTNcy)
4 – قراءة (r)	قراءة، قراءة السمات، قراءة السمات المسماة، قراءة ACLs، مزامنة الإدخال/الإخراج (rtncy)
5 - قراءة/تنفيذ (rx)	قراءة السمات وتنفيذها وقراءتها وقراءة السمات المسماة وقراءة قوائم التحكم في الوصول ومزامنة الإدخال/الإخراج (rxtncy)
6 – قراءة/كتابة (rw)	القراءة والكتابة وإلحاق البيانات وقراءة السمات وكتابة السمات وقراءة السمات المسماة وكتابة السمات المسماة وقراءة ACLs ومزامنة الإدخال/الإخراج (rwatTnNcy)
7 - قراءة/كتابة/تنفيذ (rwx)	التحكم الكامل/كافة الأذونات

كيفية عمل NFSv4.x ACLs مع Azure NetApp Files

تدعم Azure NetApp Files NFSv4.x ACLs في الأصل عندما يتم تمكين NFSv4.1 وحدة تخزين للوصول. لا يوجد أي شيء لتمكينه على وحدة التخزين لدعم ACL، ولكن ل NFSv4.1 ACLs للعمل بشكل أفضل، يلزم خادم LDAP مع مستخدمي ومجموعات UNIX لضمان أن Azure NetApp Files قادرة على حل الأساسيات المعينة على قوائم التحكم في الوصول بشكل آمن. يمكن استخدام المستخدمين المحليين مع NFSv4.x ACLs، لكنهم لا يوفرون نفس مستوى الأمان مثل قوائم التحكم بالوصول المستخدمة مع خادم LDAP.

هناك اعتبارات يجب أخذها في الاعتبار مع وظيفة ACL في Azure NetApp Files.

توريث ACL

في Azure NetApp Files، يمكن استخدام علامات توريث ACL لتبسيط إدارة ACL باستخدام NFSv4.x ACLs. عند تعيين علامة توريث، يمكن نشر قوائم التحكم في الوصول على دليل أصل إلى الدلائل الفرعية والملفات دون مزيد من التفاعل. تنفذ Azure NetApp Files سلوكيات وراثة ACL القياسية وفقا ل RFC-7530.

رفض ACEs

يتم استخدام رفض ACEs في Azure NetApp Files لتقييد مستخدم أو مجموعة بشكل صريح من الوصول إلى ملف أو مجلد. يمكن تعريف مجموعة فرعية من الأذونات لتوفير عناصر تحكم دقيقة على رفض ACE. تعمل هذه في الأساليب القياسية المذكورة في RFC-7530.

الاحتفاظ ب ACL

عند تنفيذ chmod على ملف أو مجلد في Azure NetApp Files، يتم الاحتفاظ بجميع ACEs الموجودة على ACL بخلاف قوائم التحكم في الوصول للنظام (OWNER@، GROUP@، EVERYONE@). يتم تعديل أذونات ACE هذه كما هو محدد بواسطة بتات الوضع الرقمي المحددة بواسطة الأمر chmod. يمكن تغيير ACEs التي يتم تعديلها أو إزالتها يدويا عبر nfs4_setfacl الأمر فقط.

سلوكيات NFSv4.x ACL في بيئات البروتوكول المزدوج

يشير البروتوكول المزدوج إلى استخدام كل من SMB وNFS على نفس وحدة تخزين Azure NetApp Files. يتم تحديد عناصر التحكم في الوصول إلى البروتوكول المزدوج حسب نمط الأمان الذي تستخدمه وحدة التخزين، ولكن تعيين اسم المستخدم يضمن أن مستخدمي Windows ومستخدمي UNIX الذين تم تعيينهم بنجاح إلى بعضهم البعض لديهم نفس أذونات الوصول إلى البيانات.

عندما تكون NFSv4.x ACLs قيد الاستخدام على وحدات تخزين نمط أمان UNIX، يمكن ملاحظة السلوكيات التالية عند استخدام وحدات تخزين البروتوكول المزدوج والوصول إلى البيانات من عملاء SMB.

تحتاج أسماء مستخدم Windows إلى التعيين بشكل صحيح إلى أسماء مستخدم UNIX للحصول على دقة مناسبة للتحكم في الوصول.
في وحدات تخزين نمط أمان UNIX (حيث سيتم تطبيق NFSv4.x ACLs)، إذا لم يكن هناك مستخدم UNIX صالح في خادم LDAP لمستخدم Windows للتعين إليه، استخدام مستخدم UNIX افتراضي يسمى pcuser (مع uid الرقمي 65534) للتعين.
يتم عرض الملفات المكتوبة مع مستخدمي Windows بدون عرض تعيين مستخدم UNIX صالح كما هو مملوك للمعرف الرقمي 65534، والذي يتوافق مع أسماء المستخدمين "nfsnobody" أو "لا أحد" في عملاء Linux من عمليات تحميل NFS. يختلف هذا عن المعرف الرقمي 99 الذي يظهر عادة مع مشكلات مجال معرف NFSv4.x. للتحقق من المعرف الرقمي المستخدم، استخدم ls -lan الأمر .
لا توفر الملفات ذات المالكين غير الصحيحين النتائج المتوقعة من وحدات بت وضع UNIX أو من NFSv4.x ACLs.
تتم إدارة NFSv4.x ACLs من عملاء NFS. لا يمكن لعملاء SMB عرض أو إدارة NFSv4.x ACLs.

تأثير Umask مع NFSv4.x ACLs

توفر NFSv4 ACLs القدرة على تقديم توريث ACL. يعني توريث ACL أن الملفات أو المجلدات التي تم إنشاؤها أسفل الكائنات مع مجموعة NFSv4 ACLs يمكن أن ترث قوائم التحكم بالوصول استنادا إلى تكوين علامة توريث ACL.

يتم استخدام Umask للتحكم في مستوى الأذونات الذي يتم عنده إنشاء الملفات والمجلدات في دليل. بشكل افتراضي، تسمح Azure NetApp Files ل umask بتجاوز قوائم التحكم بالوصول الموروثة، وهو السلوك المتوقع وفقا ل RFC-7530.

لمزيد من المعلومات، راجع umask.

سلوك Chmod/chown مع NFSv4.x ACLs

في Azure NetApp Files، يمكنك استخدام أوامر تغيير الملكية (chown) وتغيير أوامر بت الوضع (chmod) لإدارة أذونات الملفات والدليل على NFSv3 وNFSv4.x.

عند استخدام NFSv4.x ACLs، فإن عناصر التحكم الأكثر دقة المطبقة على الملفات والمجلد يقلل من الحاجة إلى أوامر chmod. لا يزال لدى Chown مكان، حيث لا تقوم NFSv4.x ACLs بتعيين الملكية.

عند تشغيل chmod في Azure NetApp Files على الملفات والمجلدات مع تطبيق NFSv4.x ACLs، يتم تغيير بت الوضع على الكائن. بالإضافة إلى ذلك، يتم تعديل مجموعة من قوائم التحكم في الوصول للنظام لتعكس وحدات بت الوضع هذه. إذا تمت إزالة ACEs للنظام، مسح وحدات بت الوضع. يمكن العثور على أمثلة ووصف أكثر اكتمالا في القسم الخاص ب ACEs للنظام أدناه.

عند تشغيل chown في Azure NetApp Files، يمكن تعديل المالك المعين. لا تكون ملكية الملفات بالغة الأهمية عند استخدام NFSv4.x ACLs كما هو الحال عند استخدام وحدات بت الوضع، حيث يمكن استخدام قوائم التحكم بالوصول للتحكم في الأذونات بطرق لم تتمكن من خلالها مفاهيم المالك/المجموعة/الجميع الأساسية. يمكن تشغيل Chown في Azure NetApp Files فقط كجذر (إما كجذر أو باستخدام sudo)، حيث يتم تكوين عناصر التحكم في التصدير للسماح فقط للجذر بإجراء تغييرات على الملكية. نظرا لأنه يتم التحكم في ذلك بواسطة قاعدة نهج تصدير افتراضية في Azure NetApp Files، فإن إدخالات NFSv4.x ACL التي تسمح بتعديلات الملكية لا تنطبق.

# su user1
# chown user1 testdir
chown: changing ownership of ‘testdir’: Operation not permitted
# sudo chown user1 testdir
# ls -la | grep testdir
-rw-r--r--  1 user1    root     0 Jul 12 16:23 testdir

يمكن تعديل قاعدة نهج التصدير على وحدة التخزين لتغيير هذا السلوك. في قائمة نهج التصدير لوحدات التخزين، قم بتعديل وضع Chown إلى "غير مقيد".

بمجرد تعديلها، يمكن تغيير الملكية من قبل المستخدمين بخلاف الجذر إذا كان لديهم حقوق وصول مناسبة. يتطلب هذا إذن "Take Ownership" NFSv4.x ACL (المعين بواسطة الحرف "o"). يمكن أيضا تغيير الملكية إذا كان المستخدم الذي يغير الملكية يمتلك حاليا الملف أو المجلد.

A::user1@contoso.com:rwatTnNcCy  << no ownership flag (o)

user1@ubuntu:/mnt/testdir$ chown user1 newfile3
chown: changing ownership of 'newfile3': Permission denied

A::user1@contoso.com:rwatTnNcCoy  << with ownership flag (o)

user1@ubuntu:/mnt/testdir$ chown user1 newfile3
user1@ubuntu:/mnt/testdir$ ls -la
total 8
drwxrwxrwx 2 user2 root       4096 Jul 14 16:31 .
drwxrwxrwx 5 root  root       4096 Jul 13 13:46 ..
-rw-r--r-- 1 user1 root          0 Jul 14 15:45 newfile
-rw-r--r-- 1 root  root          0 Jul 14 15:52 newfile2
-rw-r--r-- 1 user1 4294967294    0 Jul 14 16:31 newfile3

قوائم التحكم بالوصول للنظام

في كل قائمة التحكم بالوصول، هناك سلسلة من ACEs للنظام: OWNER@، GROUP@، EVERYONE@. على سبيل المثال:

A::OWNER@:rwaxtTnNcCy
A:g:GROUP@:rwaxtTnNcy
A::EVERYONE@:rwaxtTnNcy

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

# nfs4_getfacl user1-file

# file: user1-file
A::user1@CONTOSO.COM:rT
A::OWNER@:rwaxtTnNcCy
A:g:GROUP@:rwaxtTnNcy
A::EVERYONE@:rwaxtTnNcy

# chmod 755 user1-file

# nfs4_getfacl user1-file

# file: user1-file
A::OWNER@:rwaxtTnNcCy
A:g:GROUP@:rxtncy

إذا تمت إزالة ACEs للنظام هذه، فستتغير طريقة عرض الإذن بحيث تظهر وحدات البت في الوضع العادي (rwx) على أنها شرطات.

# nfs4_setfacl -x A::OWNER@:rwaxtTnNcCy user1-file
# nfs4_setfacl -x A:g:GROUP@:rxtncy user1-file
# nfs4_setfacl -x A::EVERYONE@:rxtncy user1-file
# ls -la | grep user1-file
----------  1 user1 group1     0 Jul 12 16:23 user1-file

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

سلوك المستخدم الجذر مع NFSv4.x ACLs

لا يمكن تقييد الوصول الجذر باستخدام NFSv4.x ACLs ما لم يتم سحق الجذر. سحق الجذر هو المكان الذي يتم فيه تكوين قاعدة نهج التصدير حيث يتم تعيين الجذر إلى مستخدم مجهول للحد من الوصول. يمكن تكوين الوصول الجذر من قائمة نهج التصدير الخاصة بوحدات التخزين عن طريق تغيير قاعدة نهج الوصول الجذر إلى إيقاف التشغيل.

لتكوين سحق الجذر، انتقل إلى قائمة نهج التصدير على وحدة التخزين ثم قم بتغيير "الوصول الجذر" إلى "إيقاف" لقاعدة النهج.

تأثير تعطيل جذر الوصول الجذر إلى squashes للمستخدم nfsnobody:65534المجهول . ثم يتعذر على الوصول الجذر تغيير الملكية.

root@ubuntu:/mnt/testdir# touch newfile3
root@ubuntu:/mnt/testdir# ls -la
total 8
drwxrwxrwx 2 user2  root       4096 Jul 14 16:31 .
drwxrwxrwx 5 root   root       4096 Jul 13 13:46 ..
-rw-r--r-- 1 user1  root          0 Jul 14 15:45 newfile
-rw-r--r-- 1 root   root          0 Jul 14 15:52 newfile2
-rw-r--r-- 1 nobody 4294967294    0 Jul 14 16:31 newfile3
root@ubuntu:/mnt/testdir# ls -lan
total 8
drwxrwxrwx 2  1002          0 4096 Jul 14 16:31 .
drwxrwxrwx 5     0          0 4096 Jul 13 13:46 ..
-rw-r--r-- 1  1001          0    0 Jul 14 15:45 newfile
-rw-r--r-- 1     0          0    0 Jul 14 15:52 newfile2
-rw-r--r-- 1 65534 4294967294    0 Jul 14 16:31 newfile3
root@ubuntu:/mnt/testdir# chown root newfile3
chown: changing ownership of 'newfile3': Operation not permitted

بدلا من ذلك، في بيئات البروتوكول المزدوج، يمكن استخدام NTFS ACLs للحد من الوصول الجذر بشكل دقيق.