سؤال كيف تنطبق أذونات الملفات على symlinks؟


لنفترض أن لديك هذا الهيكل:

+ directory
-- file1
-- file2
-- file3 -> /tmp/file3

file3 هو رابط لآخر file3 في مكان آخر على النظام.

الآن دعونا نقول أنا chmod 777 الدليل وجميع محتويات داخله. هل file3 في /tmp تلقي هذه الأذونات؟ أيضا ، دعنا نقول أن لدينا نفس الوضع ولكن عكسه.

/tmp/file3 -> /directory/file3

إذا قمت بتطبيق الأذونات على الملف المرتبط ، كيف يؤثر ذلك على الرابط؟


81
2018-06-27 20:42


الأصل


تؤثر الأذونات فقط على الملف ، وليس على الشفرة. - baraboom


الأجوبة:


ذلك يعتمد على كيفية الاتصال chmod والنظام الأساسي الذي تعمل عليه.

على سبيل المثال ، على نظام Linux ، man chmod يقول هذا:

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

ومع ذلك ، في Mac ، يمكن استخدام chmod لتعديل أذونات الارتباط الرمزي باستخدام خيارات مثل هذا (من man chmod):

-h إذا كان الملف رابطًا رمزيًا ، فغيّر وضع الرابط   نفسها بدلاً من الملف الذي يشير إليه الارتباط.

على سبيل المثال ، دعنا نفترض أنك على جهاز Linux لبقية هذه الإجابة.

إذا في الحالة الأولى قمت بتشغيل chmod -R 777 directory لتغيير الأذونات بشكل متكرر ، لن يتأثر هدف الرابط ، ولكن إذا قمت بذلك chmod 777 directory/*، ستكون.

إذا قمت بتغيير الأذونات على ارتباط الهدف مباشرةً ، فسيتم تنفيذ هذه الأذونات (بما أنه صفحة رجل و baraboom على سبيل المثال ، لا يتم استخدام أذونات الارتباط الفعلي لأي شيء).


سجل الاختبار للتوضيح:

$ mkdir dir && touch dir/file{1,2} /tmp/file3 && ln -s {/tmp,dir}/file3
$ ls -l dir/* /tmp/file3
-rw-r--r-- 1 user group  0 2011-06-27 22:02 /tmp/file3
-rw-r--r-- 1 user group  0 2011-06-27 22:02 dir/file1
-rw-r--r-- 1 user group  0 2011-06-27 22:02 dir/file2
lrwxrwxrwx 1 user group 10 2011-06-27 22:02 dir/file3 -> /tmp/file3

$ chmod -R 777 dir && ls -l dir/* /tmp/file3
-rw-r--r-- 1 user group  0 2011-06-27 22:02 /tmp/file3
-rwxrwxrwx 1 user group  0 2011-06-27 22:02 dir/file1
-rwxrwxrwx 1 user group  0 2011-06-27 22:02 dir/file2
lrwxrwxrwx 1 user group 10 2011-06-27 22:02 dir/file3 -> /tmp/file3

$ chmod 700 dir/* && ls -l dir/* /tmp/file3
-rwx------ 1 user group  0 2011-06-27 22:02 /tmp/file3
-rwx------ 1 user group  0 2011-06-27 22:02 dir/file1
-rwx------ 1 user group  0 2011-06-27 22:02 dir/file2
lrwxrwxrwx 1 user group 10 2011-06-27 22:02 dir/file3 -> /tmp/file3

81
2018-06-27 21:23



كان ذلك مفاجأة لي أيضا. السؤال التالي: من يفعل الأذونات على ارتباط رمزي تعني؟ - Edward Falk
لا تعد أذونات symlink لـEdwardFalk غير مقيدة حيث أن كل شيء يجب أن يكون قادراً على اجتيازها للحصول على الأذونات من الملف المرتبط. - Walf


إجابات Baraboom و peth كلاهما الصحيح: البت الإذن على الروابط الرمزية نفسها ليست ذات صلة (باستثناء على macOS ؛ انظر أدناه) ، وتغيير الإذن على ارتباط رمزي - من قبل chmod أداة سطر الأوامر أو من قبل chmod() استدعاء النظام - سيتصرف ببساطة كما لو كان يتم تنفيذه مقابل هدف الرابط الرمزي.

يقتبس وصف SUSv4 / POSIX.1-2008 من استدعاء نظام symlink ():

تكون قيم بتات وضع الملف للارتباط الرمزي الذي تم إنشاؤه غير محددة. يجب أن تتصرف جميع الواجهات المحددة بواسطة POSIX.1-2008 كما لو كانت محتويات الارتباطات الرمزية يمكن قراءتها دائمًا ، باستثناء أن قيمة بتات وضع الملف التي تم إرجاعها في st_mode مجال القانون الأساسي الهيكل غير محدد.

هنا ، "غير محدد" يترك مساحة للتفسير لكل تطبيق. تفاصيل:

  • على Linux (تم اختباره باستخدام ext4fs) ، stat() عائدات st_mode=0777، بغض النظر عن ما هو umask عندما تم إنشاء الارتباط الرمزي ؛ ls -l لذلك يعرض دائما lrwxrwxrwx للروابط الرمزية.
  • على MacOS (HFS) و FreeBSD (كلاهما UFS و ZFS) ، يكون للارتباط الرمزي إذن خاص به: chmod -h يمكن أن يلاحظ الأمر أعلاه تغيير هذا الرابط إذن (الذي يستخدم داخليا غير POSIX lchown()استدعاء النظام لتحقيق هذا) ، و stat() استدعاء النظام بإرجاع هذه القيمة لـ st_mode.

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

من ناحية أخرى ، macOS يكسر قليلا POSIX. على الرغم من أنه يمكن اتباع رابط رمزي بغض النظر عن إذن القراءة الخاص به ، readlink() فشل مع EACCES (تم رفض الإذن) إذا لم يكن لدى المستخدم إذن قراءة:

$ sudo ln -shf target symlink
$ sudo chmod -h 444 symlink
$ ls -l symlink
lr--r--r--  1 root  staff  1 Mar 14 13:05 symlink -> target
$ sudo chmod -h 000 symlink
$ ls -l symlink

ls: symlink: Permission denied
l---------  1 root  staff  1 Mar 14 13:05 symlink
$ echo kthxbye > target
$ cat symlink
kthxbye

(نلاحظ أن -> target جزء مفقود في الإخراج من الثاني ls -l الأمر ، وهذا cat symlink لا يزال نجح وطباعة محتويات target الملف على الرغم من أن المستخدم لم يكن لديه إذن القراءة على symlink.)

يبدو أن NetBSD يوفر خيار تثبيت خاص مسمى symperm التي ، في حالة تعيينها ، تتسبب في قراءة / تنفيذ أذونات الارتباط الرمزي للتحكم readlink() وارتباط الاجتياز.


2
2018-03-14 20:32





  1. إسقاط ملف الارتباط (بعد التأكد من عدم استخدامه من قبل أي عملية)
  2. ضبط umask مثل هذه الطريقة التي 777-umask = أذونات الملفات المطلوبة
  3. إنشاء ملف الارتباط من جديد

-2
2017-10-02 05:48



كيف يجيب هذا السؤال؟ - jww