مثال على MS_SHARED و MS_PRIVATE

لنفترض أننا في طرفية في مساحة أسماء الوصل الأولية، وسمنا وصلاً واحداً بأنه مشترك ووصلاً آخر بأنه خاص، ثم استعرضنا الوصلات في /proc/self/mountinfo:

sh1# mount --make-shared /mntS
sh1# mount --make-private /mntP
sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
77 61 8:17 / /mntS rw,relatime shared:1
83 61 8:15 / /mntP rw,relatime

من مخرجات /proc/self/mountinfo، نرى أن /mntS وصل مشترك في مجموعة أقران 1، وأن /mntP ليس له أوسمة اختيارية، مما يشير إلى أنه وصل خاص. أول حقلين في كل سجل في هذا الملف هما المعرف الفريد لهذا الوصل، ومعرف الوصل للأب. يمكننا معاينة هذا الملف أكثر لنرى أن الوصل الأب لـ /mntS و /mntP هو دليل الجذر /، الموصول كوصل خاص:

sh1# cat /proc/self/mountinfo | awk '$1 == 61' | sed 's/ - .*//'
61 0 8:2 / / rw,relatime

في طرفية ثانية، نُنشئ مساحة أسماء وصل جديدة حيث نشغل صدفة ثانية ونعاين الوصلات:

$ PS1='sh2# ' sudo unshare -m --propagation unchanged sh
sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
222 145 8:17 / /mntS rw,relatime shared:1
225 145 8:15 / /mntP rw,relatime

The new mount namespace received a copy of the initial mount namespace's mounts. These new mounts maintain the same propagation types, but have unique mount IDs. (The --propagation unchanged option prevents unshare(1) from marking all mounts as private when creating a new mount namespace, which it does by default.)

في الطرفية الثانية، نُنشئ وصلات فرعية تحت كل من /mntS و /mntP ونعاين الإعداد:

sh2# mkdir /mntS/a
sh2# mount /dev/sdb6 /mntS/a
sh2# mkdir /mntP/b
sh2# mount /dev/sdb7 /mntP/b
sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
222 145 8:17 / /mntS rw,relatime shared:1
225 145 8:15 / /mntP rw,relatime
178 222 8:22 / /mntS/a rw,relatime shared:2
230 225 8:23 / /mntP/b rw,relatime

مما سبق، يمكن رؤية أن /mntS/a أُنشئ كوصل مشترك (وارثاً هذا الإعداد من الوصل الأب له) و /mntP/b أُنشئ كوصل خاص.

بالعودة إلى الطرفية الأولى ومعاينة الإعداد، نرى أن الوصل الجديد المنشأ تحت الوصل المشترك /mntS قد انتشر إلى وصل قرينه (في مساحة أسماء الوصل الأولية)، لكن الوصل الجديد المنشأ تحت الوصل الخاص /mntP لم ينتشر:

sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
77 61 8:17 / /mntS rw,relatime shared:1
83 61 8:15 / /mntP rw,relatime
179 77 8:22 / /mntS/a rw,relatime shared:2

مثال على MS_SLAVE

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

يمكننا إثبات تأثير التبعية بوسم وصلين أولاً بأنهما مشتركان في مساحة أسماء الوصل الأولية:

sh1# mount --make-shared /mntX
sh1# mount --make-shared /mntY
sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
132 83 8:23 / /mntX rw,relatime shared:1
133 83 8:22 / /mntY rw,relatime shared:2

في طرفية ثانية، نُنشئ مساحة أسماء وصل جديدة ونعاين الوصلات:

sh2# unshare -m --propagation unchanged sh
sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
168 167 8:23 / /mntX rw,relatime shared:1
169 167 8:22 / /mntY rw,relatime shared:2

في مساحة أسماء الوصل الجديدة، نسم أحد الوصلات بأنه تابع:

sh2# mount --make-slave /mntY
sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
168 167 8:23 / /mntX rw,relatime shared:1
169 167 8:22 / /mntY rw,relatime master:2

من المخرجات أعلاه، نرى أن /mntY هو الآن وصل تابع يتلقى أحداث الانتشار من مجموعة الأقران المشتركة ذات المعرف 2.

بالمتابعة في مساحة الأسماء الجديدة، نُنشئ وصلات فرعية تحت كل من /mntX و /mntY:

sh2# mkdir /mntX/a
sh2# mount /dev/sda3 /mntX/a
sh2# mkdir /mntY/b
sh2# mount /dev/sda5 /mntY/b

عند معاينة حالة الوصلات في مساحة أسماء الوصل الجديدة، نرى أن /mntX/a أُنشئ كوصل مشترك جديد (وارثاً إعداد "shared" من الوصل الأب) و /mntY/b أُنشئ كوصل خاص:

sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
168 167 8:23 / /mntX rw,relatime shared:1
169 167 8:22 / /mntY rw,relatime master:2
173 168 8:3 / /mntX/a rw,relatime shared:3
175 169 8:5 / /mntY/b rw,relatime

بالعودة إلى الطرفية الأولى (في مساحة أسماء الوصل الأولية)، نرى أن الوصل /mntX/a قد انتشر إلى القرين (المشترك /mntX)، لكن الوصل /mntY/b لم ينتشر:

sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
132 83 8:23 / /mntX rw,relatime shared:1
133 83 8:22 / /mntY rw,relatime shared:2
174 132 8:3 / /mntX/a rw,relatime shared:3

الآن نُنشئ وصلاً جديداً تحت /mntY في الصدفة الأولى:

sh1# mkdir /mntY/c
sh1# mount /dev/sda1 /mntY/c
sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
132 83 8:23 / /mntX rw,relatime shared:1
133 83 8:22 / /mntY rw,relatime shared:2
174 132 8:3 / /mntX/a rw,relatime shared:3
178 133 8:1 / /mntY/c rw,relatime shared:4

عند فحص الوصلات في مساحة أسماء الوصل الثانية، نرى أنه في هذه الحالة قد انتشر الوصل الجديد إلى الوصل التابع، وأن الوصل الجديد نفسه هو وصل تابع (لمجموعة أقران 4):

sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
168 167 8:23 / /mntX rw,relatime shared:1
169 167 8:22 / /mntY rw,relatime master:2
173 168 8:3 / /mntX/a rw,relatime shared:3
175 169 8:5 / /mntY/b rw,relatime
179 169 8:1 / /mntY/c rw,relatime master:4

مثال على MS_UNBINDABLE

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

لنفترض أن لدينا نظاماً بالوصلات التالية:

# mount | awk '{print $1, $2, $3}'
/dev/sda1 on /
/dev/sdb6 on /mntX
/dev/sdb7 on /mntY

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

# mount --rbind / /home/cecilia/
# mount | awk '{print $1, $2, $3}'
/dev/sda1 on /
/dev/sdb6 on /mntX
/dev/sdb7 on /mntY
/dev/sda1 on /home/cecilia
/dev/sdb6 on /home/cecilia/mntX
/dev/sdb7 on /home/cecilia/mntY

عندما نكرر هذه العملية للمستخدم الثاني، نبدأ في رؤية مشكلة الانفجار:

# mount --rbind / /home/henry
# mount | awk '{print $1, $2, $3}'
/dev/sda1 on /
/dev/sdb6 on /mntX
/dev/sdb7 on /mntY
/dev/sda1 on /home/cecilia
/dev/sdb6 on /home/cecilia/mntX
/dev/sdb7 on /home/cecilia/mntY
/dev/sda1 on /home/henry
/dev/sdb6 on /home/henry/mntX
/dev/sdb7 on /home/henry/mntY
/dev/sda1 on /home/henry/home/cecilia
/dev/sdb6 on /home/henry/home/cecilia/mntX
/dev/sdb7 on /home/henry/home/cecilia/mntY

تحت /home/henry، لم نضف وصلات /mntX و /mntY تكرارياً فحسب، بل أضفنا أيضاً الوصلات التكرارية لتلك الأدلة تحت /home/cecilia التي أُنشئت في الخطوة السابقة. عند تكرار الخطوة لمستخدم ثالث، يصبح من الواضح أن الانفجار أسي بطبيعته:

# mount --rbind / /home/otto
# mount | awk '{print $1, $2, $3}'
/dev/sda1 on /
/dev/sdb6 on /mntX
/dev/sdb7 on /mntY
/dev/sda1 on /home/cecilia
/dev/sdb6 on /home/cecilia/mntX
/dev/sdb7 on /home/cecilia/mntY
/dev/sda1 on /home/henry
/dev/sdb6 on /home/henry/mntX
/dev/sdb7 on /home/henry/mntY
/dev/sda1 on /home/henry/home/cecilia
/dev/sdb6 on /home/henry/home/cecilia/mntX
/dev/sdb7 on /home/henry/home/cecilia/mntY
/dev/sda1 on /home/otto
/dev/sdb6 on /home/otto/mntX
/dev/sdb7 on /home/otto/mntY
/dev/sda1 on /home/otto/home/cecilia
/dev/sdb6 on /home/otto/home/cecilia/mntX
/dev/sdb7 on /home/otto/home/cecilia/mntY
/dev/sda1 on /home/otto/home/henry
/dev/sdb6 on /home/otto/home/henry/mntX
/dev/sdb7 on /home/otto/home/henry/mntY
/dev/sda1 on /home/otto/home/henry/home/cecilia
/dev/sdb6 on /home/otto/home/henry/home/cecilia/mntX
/dev/sdb7 on /home/otto/home/henry/home/cecilia/mntY

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

# mount --rbind --make-unbindable / /home/cecilia

قبل المضي قدماً، نُبين أن الوصلات غير القابلة للتقييد هي بالفعل كذلك:

# mkdir /mntZ
# mount --bind /home/cecilia /mntZ
mount: wrong fs type, bad option, bad superblock on /home/cecilia,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail or so.

الآن نُنشئ وصلات تقييدية تكرارية غير قابلة للتقييد للمستخدمين الآخرين:

# mount --rbind --make-unbindable / /home/henry
# mount --rbind --make-unbindable / /home/otto

عند فحص قائمة الوصلات، نرى أنه لم يحدث انفجار للوصلات، لأن الوصلات غير القابلة للتقييد لم تُنسخ تحت دليل كل مستخدم:

# mount | awk '{print $1, $2, $3}'
/dev/sda1 on /
/dev/sdb6 on /mntX
/dev/sdb7 on /mntY
/dev/sda1 on /home/cecilia
/dev/sdb6 on /home/cecilia/mntX
/dev/sdb7 on /home/cecilia/mntY
/dev/sda1 on /home/henry
/dev/sdb6 on /home/henry/mntX
/dev/sdb7 on /home/henry/mntY
/dev/sda1 on /home/otto
/dev/sdb6 on /home/otto/mntX
/dev/sdb7 on /home/otto/mntY

انتقالات نوع الانتشار

The following table shows the effect that applying a new propagation type (i.e., mount --make-xxxx) has on the existing propagation type of a mount. The rows correspond to existing propagation types, and the columns are the new propagation settings. For reasons of space, "private" is abbreviated as "priv" and "unbindable" as "unbind".

لاحظ التفاصيل التالية المتعلقة بالجدول:

[1]

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

[2]

لا يؤثر جعل عملية الوصل غير المشتركة تابعة على عملية الوصل.

دلالات الربط (MS_BIND)

افترض أنه نُفّذ الأمر التالي:

mount --bind A/a B/b

هنا، A هي وصلة المصدر، و B هي وصلة الوجهة، و a هو مسار دليل فرعي تحت نقطة الوصل A، و b هو مسار دليل فرعي تحت نقطة الوصل B. يعتمد نوع انتشار الوصلة الناتجة، B/b، على أنواع انتشار الوصلات A و B، وهو ملخص في الجدول التالي.

لاحظ أن الربط المتكرر لشجرة فرعية يتبع نفس الدلالات الخاصة بعملية الربط لكل وصلة في الشجرة الفرعية. (تُقلّم الوصلات غير القابلة للارتباط آليًا عند نقطة الوصل الهدف).

لمزيد من التفاصيل، راجع Documentation/filesystems/sharedsubtree.rst في شجرة مصادر النواة.

دلالات النقل (MS_MOVE)

افترض أنه نُفّذ الأمر التالي:

mount --move A B/b

هنا، A هي وصلة المصدر، و B هي وصلة الوجهة، و b هو مسار دليل فرعي تحت نقطة الوصل B. يعتمد نوع انتشار الوصلة الناتجة، B/b، على أنواع انتشار الوصلات A و B، وهو ملخص في الجدول التالي.

ملاحظة: نقل وصلة تقع تحت وصلة مشتركة أمر غير صالح.

لمزيد من التفاصيل، راجع Documentation/filesystems/sharedsubtree.rst في شجرة مصادر النواة.

دلالات الوصل

افترض أننا نستخدم الأمر التالي لإنشاء وصلة:

mount device B/b

هنا، B هي وصلة الوجهة، و b هو مسار دليل فرعي تحت نقطة الوصل B. يتبع نوع انتشار الوصلة الناتجة، B/b، نفس القواعد المتبعة في وصلة الربط، حيث يُعتبر نوع انتشار وصلة المصدر دائمًا خاصًا.

دلالات الفصل

افترض أننا نستخدم الأمر التالي لتفكيك وصلة:

umount A

هنا، A هي وصلة على B/b، حيث B هي الوصلة الأب و b هو مسار دليل فرعي تحت نقطة الوصل B. إذا كانت B مشتركة، فستُفصل جميع الوصلات الموصولة حديثًا عند b على الوصلات التي تتلقى انتشارًا من الوصلة B وليس لديها وصلات فرعية تحتها.

وسم propagate_from في /proc/ pid /mountinfo

يظهر الوسم propagate_from:X في الحقول الاختيارية لسجل /proc/pid/mountinfo في الحالات التي لا تستطيع فيها العملية رؤية السيد المباشر للتابع (أي أن مسار السيد لا يمكن الوصول إليه من دليل جذر نظام الملفات) وبالتالي لا يمكنها تحديد سلسلة الانتشار بين الوصلات التي يمكنها رؤيتها.

في المثال التالي، ننشئ أولاً سلسلة سيد-تابع من وصلتين بين الوصلات /mnt و /tmp/etc و /mnt/tmp/etc. ثم يُستخدم الأمر chroot(1) لجعل نقطة الوصل /tmp/etc غير قابلة للوصول من دليل الجذر، مما يخلق وضعًا لا يمكن فيه الوصول إلى سيد /mnt/tmp/etc من دليل الجذر (الجديد) للعملية.

أولاً، نقوم بوصل الربط لدليل الجذر على /mnt ثم وصل الربط لـ /proc عند /mnt/proc بحيث يظل نظام ملفات proc(5) مرئيًا في الموقع الصحيح في بيئة الـ chroot بعد تنفيذ chroot(1) لاحقًا.

# mkdir -p /mnt/proc
# mount --bind / /mnt
# mount --bind /proc /mnt/proc

بعد ذلك، نتأكد من أن الوصلة /mnt هي وصلة مشتركة في مجموعة أقران جديدة (بدون أقران):

# mount --make-private /mnt  # اعزله عن أي مجموعة أقران سابقة
# mount --make-shared /mnt
# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
239 61 8:2 / /mnt ... shared:102
248 239 0:4 / /mnt/proc ... shared:5

بعد ذلك، نقوم بوصل الربط لـ /mnt/etc على /tmp/etc:

# mkdir -p /tmp/etc
# mount --bind /mnt/etc /tmp/etc
# cat /proc/self/mountinfo | egrep '/mnt|/tmp/' | sed 's/ - .*//'
239 61 8:2 / /mnt ... shared:102
248 239 0:4 / /mnt/proc ... shared:5
267 40 8:2 /etc /tmp/etc ... shared:102

في البداية، تكون هاتان الوصلتان في نفس مجموعة الأقران، ولكننا نجعل /tmp/etc تابعًا لـ /mnt/etc، ثم نجعل /tmp/etc مشتركًا أيضًا، حتى يتمكن من نشر الأحداث إلى التابع التالي في السلسلة:

# mount --make-slave /tmp/etc
# mount --make-shared /tmp/etc
# cat /proc/self/mountinfo | egrep '/mnt|/tmp/' | sed 's/ - .*//'
239 61 8:2 / /mnt ... shared:102
248 239 0:4 / /mnt/proc ... shared:5
267 40 8:2 /etc /tmp/etc ... shared:105 master:102

ثم نقوم بوصل الربط لـ /tmp/etc على /mnt/tmp/etc. مرة أخرى، تكون الوصلتان في البداية في نفس مجموعة الأقران، ولكننا نجعل /mnt/tmp/etc تابعًا لـ /tmp/etc:

# mkdir -p /mnt/tmp/etc
# mount --bind /tmp/etc /mnt/tmp/etc
# mount --make-slave /mnt/tmp/etc
# cat /proc/self/mountinfo | egrep '/mnt|/tmp/' | sed 's/ - .*//'
239 61 8:2 / /mnt ... shared:102
248 239 0:4 / /mnt/proc ... shared:5
267 40 8:2 /etc /tmp/etc ... shared:105 master:102
273 239 8:2 /etc /mnt/tmp/etc ... master:105

مما سبق، نرى أن /mnt هي السيد للتابع /tmp/etc، والذي بدوره هو السيد للتابع /mnt/tmp/etc.

ثم ننفذ chroot(1) إلى دليل /mnt، مما يجعل الوصلة ذات المعرف 267 غير قابلة للوصول من دليل الجذر (الجديد):

# chroot /mnt

عند فحص حالة الوصلات داخل بيئة الـ chroot، نرى ما يلي:

# cat /proc/self/mountinfo | sed 's/ - .*//'
239 61 8:2 / / ... shared:102
248 239 0:4 / /proc ... shared:5
273 239 8:2 /etc /tmp/etc ... master:105 propagate_from:102

نرى أعلاه أن الوصلة ذات المعرف 273 هي تابع سيدها هو مجموعة الأقران 105. نقطة الوصل لهذا السيد غير قابلة للوصول، ولذلك يُعرض وسم propagate_from، مما يشير إلى أن أقرب مجموعة أقران مهيمنة (أي أقرب وصلة يمكن الوصول إليها في سلسلة التوابع) هي مجموعة الأقران ذات المعرف 102 (المقابلة لنقطة الوصل /mnt قبل تنفيذ chroot(1)).

قيود على مساحات أسماء الوصل

لاحظ النقاط التالية فيما يتعلق بمساحات أسماء الوصل:

[1]

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

[2]

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

[3]

تُقفل الوصلات التي تأتي كوحدة واحدة من مساحة اسم وصل أكثر امتيازًا معًا ولا يجوز فصلها في مساحة اسم وصل أقل امتيازًا. (تجلب عملية CLONE_NEWNS في unshare(2) جميع الوصلات من مساحة اسم الوصل الأصلية كوحدة واحدة، وتنتشر الوصلات المتكررة التي تنتشر بين مساحات أسماء الوصل كوحدة واحدة).

في هذا السياق، تعني عبارة "لا يجوز فصلها" أن الوصلات مقفلة بحيث لا يمكن فصلها بشكل فردي. تأمل المثال التالي:

$ sudo sh
# mount --bind /dev/null /etc/shadow
# cat /etc/shadow       # لا ينتج أي مخرج

أدت الخطوات المذكورة أعلاه، والتي نُفذت في مساحة اسم وصل أكثر امتيازًا، إلى إنشاء وصلة ربط تحجب محتويات ملف كلمة السر الخفي، /etc/shadow. لأسباب أمنية، لا ينبغي أن يكون من الممكن فصل (umount(2)) تلك الوصلة في مساحة اسم وصل أقل امتيازًا، لأن ذلك سيكشف عن محتويات /etc/shadow.

افترض أننا ننشئ الآن مساحة اسم وصل جديدة مملوكة لمساحة اسم مستخدم جديدة. ستَرث مساحة اسم الوصل الجديدة نسخًا من جميع الوصلات من مساحة اسم الوصل السابقة. ومع ذلك، ستُقفل تلك الوصلات لأن مساحة اسم الوصل الجديدة أقل امتيازًا. وبناءً على ذلك، ستفشل محاولة فصل (umount(2)) الوصلة كما هو موضح في الخطوة التالية:

# unshare --user --map-root-user --mount \
strace -o /tmp/log \
umount /etc/shadow
umount: /etc/shadow: not mounted.
# grep '^umount' /tmp/log
umount2("/etc/shadow", 0)     = -1 EINVAL (Invalid argument)

رسالة الخطأ من mount(8) مربكة قليلاً، لكن مخرجات strace(1) تكشف أن استدعاء النظام umount2(2) الأساسي فشل مع الخطأ EINVAL، وهو الخطأ الذي ترجعه النواة للإشارة إلى أن الوصلة مقفلة.

لاحظ، مع ذلك، أنه من الممكن تكديس (وفك تكديس) وصلة فوق إحدى الوصلات المقفلة الموروثة في مساحة اسم وصل أقل امتيازًا:

# echo 'aaaaa' > /tmp/a    # ملف لوصله على /etc/shadow
# unshare --user --map-root-user --mount \
sh -c 'mount --bind /tmp/a /etc/shadow; cat /etc/shadow'
aaaaa
# umount /etc/shadow

أمر umount(8) الأخير أعلاه، والذي نُفذ في مساحة اسم الوصل الأولية، يجعل ملف /etc/shadow الأصلي مرئيًا مرة أخرى في مساحة الاسم تلك.

[4]

إلحاقًا بالنقطة [3]، لاحظ أنه من الممكن فصل (umount(2)) شجرة فرعية كاملة من الوصلات التي انتشرت كوحدة واحدة إلى مساحة اسم وصل أقل امتيازًا، كما هو موضح في المثال التالي.

أولاً، ننشئ مساحات أسماء مستخدم ووصل جديدة باستخدام unshare(1). في مساحة اسم الوصل الجديدة، ضُبط نوع انتشار جميع الوصلات ليكون خاصًا. ثم ننشئ وصلة ربط مشتركة عند /mnt، وهرمية صغيرة من الوصلات تحت تلك الوصلة.

$ PS1='ns1# ' sudo unshare --user --map-root-user \
--mount --propagation private bash
ns1# echo $$        # سنحتاج إلى PID هذه الصدفة لاحقًا
778501
ns1# mount --make-shared --bind /mnt /mnt
ns1# mkdir /mnt/x
ns1# mount --make-private -t tmpfs none /mnt/x
ns1# mkdir /mnt/x/y
ns1# mount --make-private -t tmpfs none /mnt/x/y
ns1# grep /mnt /proc/self/mountinfo | sed 's/ - .*//'
986 83 8:5 /mnt /mnt rw,relatime shared:344
989 986 0:56 / /mnt/x rw,relatime
990 989 0:57 / /mnt/x/y rw,relatime

استمرارًا في نفس جلسة الصدفة، ننشئ صدفة ثانية في مساحة اسم مستخدم جديدة ومساحة اسم وصل جديدة (أقل امتيازًا) ونتحقق من حالة الوصلات المنتشرة المتجذرة عند /mnt.

ns1# PS1='ns2# ' unshare --user --map-root-user \
--mount --propagation unchanged bash
ns2# grep /mnt /proc/self/mountinfo | sed 's/ - .*//'
1239 1204 8:5 /mnt /mnt rw,relatime master:344
1240 1239 0:56 / /mnt/x rw,relatime
1241 1240 0:57 / /mnt/x/y rw,relatime

مما يلاحظ في المخرج أعلاه هو أن نوع انتشار الوصلة /mnt قد اختُزل إلى تابع، كما هو موضح في النقطة [2]. وهذا يعني أن أحداث الوصل الفرعي ستنتشر من السيد /mnt في "ns1"، ولكن الانتشار لن يحدث في الاتجاه المعاكس.

من نافذة طرفية منفصلة، نستخدم nsenter(1) للدخول إلى مساحات أسماء الوصل والمستخدم المقابلة لـ "ns1". في تلك النافذة الطرفية، نقوم بعد ذلك بوصل ربط متكرر لـ /mnt/x عند الموقع /mnt/ppp.

$ PS1='ns3# ' sudo nsenter -t 778501 --user --mount
ns3# mount --rbind --make-private /mnt/x /mnt/ppp
ns3# grep /mnt /proc/self/mountinfo | sed 's/ - .*//'
986 83 8:5 /mnt /mnt rw,relatime shared:344
989 986 0:56 / /mnt/x rw,relatime
990 989 0:57 / /mnt/x/y rw,relatime
1242 986 0:56 / /mnt/ppp rw,relatime
1243 1242 0:57 / /mnt/ppp/y rw,relatime shared:518

نظرًا لأن نوع انتشار الوصل الأب، /mnt، كان مشتركًا، فقد نشر الوصل المربوط العودي (recursive bind mount) شجيرة وصلات صغيرة تحت الوصل التابع /mnt إلى "ns2"، كما يمكن التحقق من ذلك بتنفيذ الأمر التالي في جلسة الصدفة تلك:

ns2# grep /mnt /proc/self/mountinfo | sed 's/ - .*//'
1239 1204 8:5 /mnt /mnt rw,relatime master:344
1240 1239 0:56 / /mnt/x rw,relatime
1241 1240 0:57 / /mnt/x/y rw,relatime
1244 1239 0:56 / /mnt/ppp rw,relatime
1245 1244 0:57 / /mnt/ppp/y rw,relatime master:518

في حين أنه لا يمكن فصل (umount(2)) جزء من الشجيرة المنشورة (/mnt/ppp/y) في "ns2"، إلا أنه يمكن فصل الشجيرة بأكملها، كما هو موضح في الأوامر التالية:

ns2# umount /mnt/ppp/y
umount: /mnt/ppp/y: not mounted.
ns2# umount -l /mnt/ppp | sed 's/ - .*//'      # ينجح...
ns2# grep /mnt /proc/self/mountinfo
1239 1204 8:5 /mnt /mnt rw,relatime master:344
1240 1239 0:56 / /mnt/x rw,relatime
1241 1240 0:57 / /mnt/x/y rw,relatime

[5]

تصبح إعدادات أعلام mount(2) المسماة MS_RDONLY و MS_NOSUID و MS_NOEXEC، وأعلام "atime" (مثل MS_NOATIME و MS_NODIRATIME و MS_RELATIME) مقفلة عند انتشارها من مساحة اسم وصل أكثر امتيازًا إلى مساحة اسم وصل أقل امتيازًا، ولا يجوز تغييرها في مساحة اسم الوصل الأقل امتيازًا.

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

$ sudo mkdir /mnt/dir
$ sudo mount --bind -o ro /some/path /mnt/dir
$ sudo unshare --user --map-root-user --mount \
mount -o remount,rw /mnt/dir
mount: /mnt/dir: permission denied.

[6]

إن الملف أو الدليل الذي يعد نقطة وصل في مساحة اسم واحدة ولكنه ليس نقطة وصل في مساحة اسم أخرى، يجوز إعادة تسميته أو فك ربطه أو إزالته (rmdir(2)) في مساحة اسم الوصل التي لا يكون فيها نقطة وصل (يخضع ذلك لفحوصات الأذونات المعتادة). ونتيجة لذلك، تُزال نقطة الوصل في مساحة اسم الوصل التي كانت فيها نقطة وصل.

سابقًا (قبل لينكس 3.18)، كانت محاولة فك ربط أو إعادة تسمية أو إزالة ملف أو دليل كان يمثل نقطة وصل في مساحة اسم وصل أخرى تؤدي إلى الخطأ EBUSY. كان لهذا السلوك مشكلات تقنية في الإنفاذ (على سبيل المثال، لـ NFS) وسمح بشن هجمات حجب الخدمة ضد المستخدمين الأكثر امتيازًا (أي منع تحديث ملفات فردية عن طريق عمل وصل مربط فوقها).