동일한 파일 시스템의 "mount --bind" 디렉터리에서 파일에 대한 "하드 링크"를 생성할 수 없는 이유는 무엇입니까?

동일한 파일 시스템의 "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

노트: 좀 더 명확하게 하기 위해 파일명과 디렉터리명을 수동으로 변경했기 때문에 명령을 읽는 데 오타가 한두 군데 있을 수 있습니다.

답변1

실망스러운 리뷰 부족암호. v2.4에서는 바인드 마운트가 구현되었기 때문에 아무도 그것이 유용하다고 생각하지 않은 것 같습니다. 물론, 당신이 해야 할 일은 .mnt->mnt_sb그것이 말하는 곳을 바꾸는 것뿐입니다 .mnt...

하위 트리 주위에 안전한 경계를 제공하기 때문입니다.

추신: 이것은 여러 번 논의되었지만 검색을 피하기 위해: 예를 들어 mount --bind /tmp /tmp를 고려하십시오. 이제 사용자가 루트 파일 시스템 없이는 다른 위치에 대한 링크를 만들 수 없는 상황이 있습니다. 심지어 /tmp 쓰기가 가능합니다. . 유사한 기술이 다른 격리 요구 사항에도 적용됩니다. 기본적으로 특정 하위 트리에 대한 이름 바꾸기/링크를 제한할 수 있습니다. IOW, 이것은 의도적인 기능입니다. 1년 후 메인 트리에서 상황이 어떻게 재배치되더라도 여러 개의 트리를 chroot에 묶어 예측 가능한 제한을 얻을 수 있습니다.

--알베이로

스레드 아래에 구체적인 예가 있습니다.

mount -r --bind 작업을 수행할 때마다(페이지 캐시 공유를 허용하면서 필요한 공유 라이브러리의 복사본을 chroot 감옥에 배치하는 데 사용함) 이 기능은 보안을 깨뜨립니다.

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에 두는 것을 피하고 싶습니다.

답변2

기기 간 연결을 할 수 없는 이유는 모호함을 유발하기 때문입니다. 파일의 디렉토리 항목에는 (간단한 시스템에서) 관련 파일의 inode 번호가 포함됩니다. 하드 링크(다른 디렉토리 항목)에도 동일한 inode 번호가 포함되어야 합니다. 괜찮지만 inode 번호는 단일 파일 시스템 내에서만 고유합니다(보통 1부터 시작하는 밀집된 세트입니다).

번들 설치로는 문제가 해결되지 않습니다. 예, 구조의 "허구"를 구축하지만 파일 시스템의 모든 i-노드 번호를 다시 지정하여 관련 파일 시스템 내에서 모두 고유한지 확인하는 것은 아닙니다. 그건 멍청한 짓이야.

이 제한은 UNIX 시스템에서 항상 존재했습니다. 이 문제를 해결하기 위해 부분적으로 심볼릭 링크가 고안되었습니다. 나는 그들이 기능적으로 동일하지 않다는 것을 알고 있지만 일반적으로 좋습니다.

심볼릭 링크를 사용해 보시겠습니까? ( ln -s)

관련 정보