Dlaczego nie mogę utworzyć „twardego łącza” do pliku z katalogu „mount --bind” w tym samym systemie plików?

Oryginalny problem

Mam plik w jednym systemie plików: /data/src/file

i chcę na stałe połączyć go z: /home/user/proj/src/file

ale /homejest na jednym dysku i /datana innym, więc pojawia się błąd:

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

Okej, więc dowiedziałem się, że nie mogę na stałe połączyć się między urządzeniami Ma sens.

Problem pod ręką

Pomyślałem więc, że zrobię coś fantazyjnego i powiążę zamontowanie srcfolderu w /datasystemie plików:

$ 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

Dlaczego to nadal nie działa?

Obejście

Wiem, że mam prawidłową konfigurację, ponieważ mogę utworzyć twardy link, dopóki jestem w katalogu „prawdziwym” /datazamiast w powiązanym.

$ 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

$

Niektóre informacje o systemie

$ 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

Uwaga : ręcznie zmieniłem nazwy plików i katalogów, aby sytuacja była bardziej przejrzysta, więc może być literówka lub dwie w odczytach poleceń.

W kodzie jest rozczarowujący brak komentarzy . To tak, jakby nikt nigdy nie uważał tego za użyteczne, ponieważ montowania powiązań czasowych zostały zaimplementowane w wersji 2.4. Z pewnością wszystko, co musisz zrobić, to zastąpić .mnt->mnt_sbtam, gdzie jest napisane .mnt...

Ponieważ daje to granicę bezpieczeństwa wokół poddrzewa.

PS: zostało to omówione kilka razy, ale aby uniknąć wyszukiwania: rozważ np. Mount --bind / tmp / tmp; teraz masz sytuację, w której użytkownicy nie mogą tworzyć linków do innych plików bez rootowania, nawet jeśli mają zapis / tmp do nich zapisywalny. Podobne techniki działają w przypadku innych potrzeb związanych z izolacją - w zasadzie możesz ograniczyć nazwę / link do danego poddrzewa. IOW, to celowa funkcja. Pamiętaj, że możesz powiązać wiązkę drzew w chroot i uzyskać przewidywalne ograniczenia, niezależnie od tego, jak rzeczy mogą zostać uporządkowane rok później w głównym drzewie itp.

- Al Viro

Poniżej jest konkretny przykład

Ilekroć otrzymujemy mount -r --bind działający poprawnie (którego używam do umieszczania kopii niezbędnych bibliotek współdzielonych w więzieniach chroot, jednocześnie umożliwiając współdzielenie pamięci podręcznej strony), funkcja ta naruszyłaby bezpieczeństwo.

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 &

Chociaż zabezpieczenia powinny wystarczyć, ale wolałbym unikać linku więźnia /jail/lib/libfoo.so (zapis zwraca EROFS) do / jail / usr / log, gdzie jest potencjalnie zapisywalny.

Powodem, dla którego nie możesz łączyć między urządzeniami, jest wprowadzanie niejednoznaczności. Pozycja katalogu dla pliku zawiera (w prostych systemach) numer i-węzła dla danego pliku. Dowiązanie twarde (tylko kolejny wpis w katalogu) musi również zawierać ten sam numer i-węzła. To dobrze, ale numery i-węzłów są unikalne tylko w jednym systemie plików (zwykle są gęstym zestawem od 1).

Twój bind mount nie rozwiązuje tego problemu. Tak, konstruuje swoistą „fikcję” struktury, ale nie wykonuje ponownej numeracji wszystkich i-węzłów w jednym systemie plików, aby upewnić się, że wszystkie są unikalne w obu systemach plików! To byłoby głupie.

To ograniczenie zawsze obowiązywało w systemach UNIX. Link symboliczny został wynaleziony częściowo w celu rozwiązania tego. Wiem, że nie są funkcjonalnie takie same, ale zazwyczaj są OK.

Spróbuj dowiązania symbolicznego? ( ln -s)