Чому я не можу створити "жорстке посилання" до файлу з каталогу "mount --bind" в тій же файловій системі?

Оригінальна проблема

У мене є файл в одній файловій системі: /data/src/file

і я хочу важко пов’язати це: /home/user/proj/src/file

але /homeна одному диску, а /dataна іншому, тому я отримую помилку:

$ cd /home/user/proj/src
$ ln /data/src/file .
ln: failed to create hard link './file' => '/data/src/file': Invalid cross-device link

Гаразд, тому я дізнався, що не можу важко зв’язатись між пристроями. Має сенс.

Проблема під рукою

Тож я подумав, що захоплюсь і прив’яжу монтувати srcпапку, що знаходиться у /dataфайловій системі:

$ mkdir -p /data/other/src
$ cd /home/user/proj
$ sudo mount --bind /data/other/src src/
$ cd src
$ # (now we're technically on `/data`'s file system, right?)
$ ln /data/src/file .
ln: failed to create hard link './file' => '/data/src/file': Invalid cross-device link

Чому це все ще не працює?

Обхід

Я знаю, що у мене є така настройка правильно, тому що я можу зробити жорстке посилання, якщо я перебуваю у «справжньому» /dataкаталозі замість прив’язаного.

$ cd /data/other/src
$ ln /data/src/file .
$ # OK
$ cd /home/user/proj/src
$ ls -lh
total 35M
-rw------- 2 user user 35M Jul 17 22:22 file

$

Деякі відомості про систему

$ uname -a
Linux <host> 4.10.0-24-generic #28-Ubuntu SMP Wed Jun 14 08:14:34 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

$ findmnt
.
.
.
├─/home                               /dev/sdb8   ext4       rw,relatime,data=ordered
│ └─/home/usr/proj/src             /dev/sda2[/other/src]
│                                                 ext4       rw,relatime,data=ordered
└─/data                               /dev/sda2   ext4       rw,relatime,data=ordered

$ mountpoint -d /data
8:2

$ mountpoint -d /home/usr/proj/src/
8:2

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

У коді невтішно бракує коментарів . Це так, ніби ніхто ніколи не вважав це корисним, оскільки моменти прив'язки часу були реалізовані в v2.4. Безумовно, все, що вам потрібно буде зробити, це підміняти .mnt->mnt_sbтам, де написано .mnt...

Тому що це дає вам межу безпеки навколо піддерева.

PS: про це говорилося досить багато разів, але щоб уникнути пошуків: врахуйте, наприклад, mount --bind / tmp / tmp; тепер у вас виникла ситуація, коли користувачі не можуть створювати посилання на інше місце, де немає кореневих файлів, навіть якщо вони / tmp можуть писати для них. Подібна техніка працює для інших потреб в ізоляції - в основному, ви можете обмежити перейменування / посилання на задане піддірево. IOW, це навмисна риса. Зауважте, що ви можете зв’язати купу дерев у chroot та отримати передбачувані обмеження незалежно від того, як речі можуть бути переставлені через рік у головне дерево тощо.

- Аль Віро

Далі є конкретний приклад

Кожного разу, коли ми працюємо mount -r --bind належним чином (що я використовую для розміщення копій необхідних спільних бібліотек у chroot jails, дозволяючи спільний кеш сторінки), ця функція порушує безпеку.

mkdir /usr/lib/libs.jail
for i in $LIST_OF_LIBRARIES; do
ln /usr/lib/$i /usr/lib/libs.jail/$i
done
mount -r /usr/lib/libs.jail /jail/lib
chown prisoner /usr/log/jail
mount /usr/log/jail /jail/usr/log
chrootuid /jail prisoner /bin/untrusted &

Хоча захисту має бути достатньо, але я б краще уникати того, щоб ув'язнений посилався /jail/lib/libfoo.so (запис повертається EROFS) до / jail / usr / log, де це потенційно можна записати.

Причина, що ви не можете здійснювати взаємозв’язок між пристроями, полягає в тому, що ви вносите неоднозначності. Запис у файл для файлу містить (у простих системах) номер i-вузла для відповідного файлу. Жорстке посилання (лише інша запис каталогу) також має містити той самий номер i-вузла. Це добре, але номери i-вузлів унікальні лише в одній файловій системі (вони зазвичай є щільним набором, починаючи з 1).

Ваша прив'язка не вирішує цю проблему. Так, він створює своєрідну «вигадку» структури, але те, що вона не робить, - перенумерувати всі i-вузли в одній файловій системі, щоб переконатися, що вони всі унікальні для обох відповідних файлових систем! Це було б нерозумно.

Це обмеження завжди було в системах UNIX. Символічне посилання було винайдено частково для вирішення цього питання. Я знаю, що вони функціонально не однакові, але зазвичай вони нормальні.

Спробуйте символічне посилання? ( ln -s)