Створення жорстких посилань - дозволи?

Які дозволи впливають на створення жорстких посилань? Чи має значення саме право власності на файл?

Припустимо, користувач aliceхоче створити жорстке посилання на файл target.txtу каталозі target-dir.

• Які дозволи aliceпотрібні і для, target.txtі target-dir?
• Якщо target.txtналежить користувачеві billі target-dirналежить користувачеві chad, чи це щось змінює?

Я намагався моделювати цю ситуацію, створюючи таку структуру папок / файлів у ext4файловій системі:

#> ls -lh . *
.:
drwxr-xr-x 2 bill bill 60 Oct  1 11:29 source-dir
drwxrwxrwx 2 chad chad 60 Oct  1 11:40 target-dir

source-dir:
-r--r--r-- 1 bill bill 0 Oct  1 11:29 target.txt

target-dir:
-rw-rw-r-- 1 alice alice 0 Oct  1 11:40 dummy

Хоча aliceможе створити м'яке посилання на target.txt, вона не може створити жорстке посилання:

#> ln source-dir/target.txt target-dir/
ln: failed to create hard link ‘target-dir/target.txt’ => ‘source-dir/target.txt’: Operation not permitted

Якщо права aliceвласності target.txtта дозволів не змінені, жорстке посилання є успішним. Що я тут пропускаю?

Для створення жорсткого посилання aliceзнадобляться write+executeдозволи target-dirна всі випадки. Необхідні дозволи target.txtзалежать від:

• Якщо fs.protected_hardlinks = 1тоді aliceпотрібно або право власності на нього, target.txtабо принаймні read+writeдозволи на нього.
• Якщо fs.protected_hardlinks = 0тоді буде виконано будь-який набір дозволів; Навіть 000 - це нормально.

Ця відповідь на подібне запитання мала відсутність інформації, щоб відповісти на це запитання.

З http://kernel.opensuse.org/cgit/kernel/commit/?id=800179c9b8a1 [мій акцент]:

Жорсткі посилання:

У системах, які мають доступні для запису користувачеві каталоги на тому ж розділі, що і системні файли, давним класом проблем безпеки є гонка на основі жорсткої посилання "час перевірки час використання часу", що найчастіше зустрічається у світових каталогах, що записуються. як / tmp. Поширений метод експлуатації цього недоліку полягає в перетині меж привілеїв при дотриманні заданого жорсткого посилання (тобто кореневий процес слід за жорсткою посиланням, створеним іншим користувачем). Крім того, існує проблема, коли користувачі можуть "закріпити" потенційно вразливий файл setuid / setgid, щоб адміністратор фактично не оновив систему повністю.

Рішення полягає в тому, щоб дозволити створення жорстких посилань лише тоді, коли користувач уже є власником файлу або якщо він вже має доступ для читання / запису до існуючого файлу .

aliceпотрібно хоча б прочитати дозвіл на target.txtі написати + виконати дозвіл на target-dir.

Тепер структура дозволів працює як трикратний розділений набір:

1. Дозволи користувача: застосовуються до користувача, якому належить вузол.
2. Групові дозволи: застосовуються до будь-якого користувача, що належить до групи, якій належить вузол.
3. Дозвіл інших: застосувати до будь-якого іншого користувача / групи, що не володіє вузлом.

Отже, питання власності стосується лише того, у якому наборі дозволів потрібні дозволи alice:

• Якщо aliceце власник користувача, необхідні дозволи повинні бути у частині "користувач".
• Якщо aliceце частина групи, яка їй належить, необхідні дозволи повинні бути в частині "групу".
• Якщо aliceвін не є його власником і не входить до групи, яка йому належить, необхідні дозволи повинні бути в частині "інша".