Por que não consigo criar um 'hardlink' para um arquivo de um diretório “mount -bind” no mesmo sistema de arquivos?

Question

Problema Original

Eu tenho um arquivo em um sistema de arquivos: /data/src/file

e quero vinculá-lo a: /home/user/proj/src/file

mas /home está em um disco e /data está em outro, por isso recebo um erro:

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

Ok, aprendi que não posso estabelecer links rígidos entre dispositivos. Faz sentido.

Problema na mão

Então, achei que seria interessante montar uma pasta src no sistema de arquivos /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

Por que isso ainda não funciona?

Solução alternativa

Eu sei que tenho essa configuração certa, porque posso fazer o link físico, desde que eu esteja no diretório "real" /data , em vez do link.

$ 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

$

Algumas informações do sistema

$ 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

Observação : eu alterei manualmente os nomes de arquivo e diretório para tornar a situação mais clara, então pode haver um erro de digitação ou dois nas leituras de comando.

    

Answer 1

Há uma decepcionante falta de comentários no código . É como se ninguém jamais achasse útil, uma vez que as montagens de bind de tempo foram implementadas na v2.4. Certamente tudo que você precisa fazer é substituir .mnt->mnt_sb , onde diz .mnt ...

Because it gives you a security boundary around a subtree.

     

PS: isso foi discutido várias vezes, mas para evitar buscas:   considerar, por exemplo mount --bind / tmp / tmp; agora você tem uma situação quando   os usuários não podem criar links para outros lugares sem root fs, embora eles   tem / tmp gravável para eles. Técnicas semelhantes funcionam para outro isolamento   precisa - basicamente, você pode restringir renomear / link para subárvore dada. IOW   é uma característica deliberada. Note que você pode ligar um monte de árvores   em chroot e obter restrições previsíveis, independentemente de como o   coisas podem ser rearranjadas um ano depois na árvore principal, etc.

- Al Viro

Há um exemplo concreto mais abaixo no tópico

Whenever we get mount -r --bind working properly (which I use to place copies of necessary shared libraries inside chroot jails while allowing page cache sharing), this feature would break security.

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 &

Although protections should be enough, but I'd rather avoid having the prisoner link /jail/lib/libfoo.so (write returns EROFS) to /jail/usr/log where it's potentially writeable.

    

Answer 2

A razão pela qual você não pode fazer links entre dispositivos é porque você introduz ambigüidades. A entrada de diretório para o arquivo contém (em sistemas simples) o número do nó i para o arquivo em questão. Um link físico (apenas outra entrada de diretório) também deve conter o mesmo número de nó i. Isso é bom, mas os números de i-node são únicos em um único sistema de arquivos (eles geralmente são um conjunto denso começando em 1).

Sua montagem de ligação não corrige esse problema. Sim, ele constrói um tipo de 'ficção' da estrutura, mas o que ele não faz é renumerar todos os i-nodes em um sistema de arquivos para garantir que eles sejam exclusivos em ambos os sistemas de arquivos em questão! Isso seria bobo.

Essa restrição sempre existiu nos sistemas UNIX. O link simbólico foi inventado em parte para resolver isso. Eu sei que eles não são funcionalmente iguais, mas eles geralmente são OK.

Tente um link simbólico? ( ln -s )