☰

"내가 놓친 게 무엇입니까"

tag-icon • tag-icon permissions filesystems directory inode
"내가 놓친 게 무엇입니까"

내가 이해한 바에 따르면, 디렉토리에 대한 "읽기" 권한은 모든 디렉토리 목록을 허용합니다.이름그 디렉토리 안에는 그게 전부입니다.

FS 설계에 대한 일반적인 이해에 따르면 디렉터리가 파일로 저장되는 경우 해당 콘텐츠에는 최소한 파일 이름 외에 해당 inode에 대한 참조가 포함되어야 합니다. Unix의 "모든 것은 파일이다"라는 철학을 사용하여 "읽기" 권한은 디렉토리 자체의 "파일 내용"에 대한 액세스를 부여합니다.~해야 한다각 파일의 inode 번호를 검색하는 것으로 충분합니다. 그러나 이는 사실이 아니다.

내가 여기서 무엇을 놓치고 있는 걸까요?

답변1

~처럼@muru가 말했습니다., 디렉토리 내용을 읽으면(디렉토리가 초기 Unices와 같은 일반 파일로 구현되었는지 여부에 관계없이) inode 번호(Linux뿐만 아니라 모든 POSIX 시스템에서)를 확실히 얻을 수 있습니다.

당신이 그것을 할 수 없다고 생각하게 만드는 것은 당신이 노력했기 때문일 수 있습니다.

ls -i dir

당신이 소유한 디렉토리에읽다하지만찾다라이선스를 확인하고 다음을 확인하세요.

file1: Permission denied
file2: Permission denied

이는 구현 에서 단순히 항목을 인쇄하는 것이 아니라 반환된 각 항목에 대해 작업을 수행 ls하려고 하기 때문입니다 .lstat()readdir()d_ino

모든 구현이 이를 수행하는 것은 아닙니다. 예를 들어, lsksh93의 내장 함수(빌드 시 포함되고 를 사용하여 활성화된 경우 builtin ls)는 각 파일을 ing하는 대신 d_inoing으로 반환된 내용을 인쇄합니다 .readdir()lstat()

ls대부분의 구현에서 inode 번호 검색을 사용하는 한 가지 이유는 lstat()아마도 마운트 지점인 파일에 대해 잘못된 inode 번호를 얻는 경우가 많기 때문일 것입니다.

% ksh93 -o emacs
$ builtin ls
$ /bin/ls -i /
    21 bin        28 home-blank       6 lost+found      22 root       5 tmp
     2 boot        9 home-test       26 media            1 run        2 u
     8 cdrom      14 lib             17 mnt             15 sbin      13 usr
     1 dev        23 lib32       855691 opt             25 snap  229376 var
    19 etc        20 lib64           34 pool0           18 srv
    34 home        4 libx32           1 proc             1 sys
$ ls -i /
    21 bin        28 home-blank       6 lost+found      22 root       5 tmp
    24 boot        9 home-test       26 media           12 run        2 u
     8 cdrom      14 lib             17 mnt             15 sbin      13 usr
     3 dev        23 lib32       855691 opt             25 snap  229376 var
    19 etc        20 lib64           11 pool0           18 srv
265966 home        4 libx32           7 proc            16 sys

ksh93의 내장 함수가 루트 파일 시스템에서 마운트 지점(예 /boot: , , /proc위 /sys) 인 파일의 inode 번호와 (내 경우에는 GNU ) 해당 파일의 유효 inode 번호, 즉 inode 번호를 제공하는 방법을 이해합니다. 루트 파일 시스템의 번호와 파일 시스템이 설치된 디렉터리입니다.ls/bin/lsls

A는 어쨌든 파일에 대해 수행 ls -id some/file됩니다 lstat()(ksh93은 ls실제로 stat()POSIX와 호환되지 않도록 만들기 위해 a를 수행합니다).

$ ls -id /boot
     2 /boot

(ksh93과 GNU를 모두 사용 ls)

답변2

적어도 내가 시도한 Linux 시스템에서는 그렇습니다.

설정:

mkdir foo
touch foo/bar
# remove as much permission as possible, so that the program still works (only leave `r`).
chmod ugo-wx foo
chmod ugo+r #incase your umask, caused it not to be set
sudo chown root:root foo -R

그리고:

//readinode.cpp
#include <iostream>
#include <dirent.h>

int main(int argc, char* argv[])
{
    for (int i = 1; i < argc; i++)
    {
        auto dir = opendir(argv[i]);
        for(auto direntry = readdir(dir); direntry; direntry = readdir(dir))
        {
            std::cout << direntry->d_ino << ' ' << direntry->d_name << '\n';
        }
    }
}

나는 얻다:

% ./readinode foo
3933790 .
3932162 ..
3933910 bar

답변3

"내가 놓친 게 무엇입니까"

inode 정보를 얻지 못했다는 주장이 틀렸다고 생각하지 마십시오. 비록 inode의 개념이 UNIX가 아닌 파일 시스템과 다르게 매핑되어 있더라도 말입니다.

하지만 내 생각에 당신이 놓치고 있는 것은 당신이 혼란스럽다는 것입니다.이상적인 사용자 인터페이스("모든 것이 파일이다") 대구현 세부정보:
나는 당신이 파일 시스템 디렉토리 개념의 내부 구조에 대해 단지 가정을 하려고 한다고 말하고 싶습니다.

디렉토리 구현 방법에 관계없이 액세스 의미는 다음과 같습니다.한정된거기에는 실제로 이해할 것이 아무것도 없습니다(또는 반대로 오해할 것도 없습니다). 그것이 바로 그들이 정의하는 방식입니다. 파일 시스템의 내부 구조는 이에 영향을 미치지 않습니다.

개인적인 의견

"파일로 저장된 디렉토리"가하나파일 시스템이 디렉토리를 구현하는 방식. 이것은 유일한 것이 아닙니다.이것이 기사에서는 Linux 커널에서 가장 오래된 POSIX 스타일 파일 시스템 중 하나가 파일과 같은 작은 디렉터리 항목 목록을 처리하지 않는 방법을 설명합니다. 디렉터리 항목은 데이터 범위에 저장되지 않지만 일반적으로 데이터 범위 설명자 목록은 데이터 범위에 저장됩니다. 작은 디렉토리의 경우 B+ 트리이고, 큰 디렉토리의 경우 B+ 트리이며 그 자체는 익스텐트(XFS 알고리즘 및 데이터 구조 3판,두번째. 17.5 및 16.2) - 그러나 파일을 연속 범위로 매핑하는 것보다 더 중요한 것은 없습니다.

따라서 "디렉토리 안에 파일만 있을 뿐"이라는 가정은 실제로 성립되지 않습니다.
솔직히 마지막 버전이 언제인지는 모르겠습니다. XFS는 1993/94년에 시작되어 현재 22년 동안 Linux에 있었습니다. ext3과 이후 ext4도 디렉토리에 대해 비슷한 블록 트리 접근 방식을 사용했으며 ext3도 2001년부터 존재했습니다. 솔직히 여기서 ext2를 고려하는 것이 타당한지 모르겠습니다. 저는 2008년 이후로 사람들이 ext2 파일 시스템을 사용하도록 설정하지 않았습니다. 로깅이 없는 ext3은 항상 그에 비해 심각한 이점을 갖고 있었으며 Linux 배포판과 임베디드 도구도 같은 방식으로 보는 경향이 있습니다.

답변4

그것은 개 공원에 있는 것과 같습니다. 모든 것이 강아지입니다. 이것은 일반 개 한 마리가 있고 나머지 개는 단지 다른 마스크를 쓴 이 개라는 의미는 아닙니다. 이것은 그들 모두가 일종의 개 속성을 가지고 있음을 의미합니다.

  • 그들은 모두 이름을 가지고 있습니다.
  • 모두 이름을 바꿀 수 있습니다.
  • 그들은 모두 개 공원/주소록에서 어울립니다.
  • 동일한 파일 시스템의 다른 디렉터리로 전송할 수 있습니다.
  • 여기에는 모두 데이터가 포함되어 있지만 반드시 같은 방식일 필요는 없습니다. 일부 파일은 다른 파일보다 다른 파일과 더 유사합니다. 예를 들어 블록 장치 파일은 디렉터리라기보다는 일반 파일과 비슷합니다. 일반 파일 및 블록 장치는 파이프, 스트림, 소켓 및 문자 장치와 유사하지만 그 반대는 아닙니다.

파일에는 일련의 인터페이스가 있을 수 있습니다. 여기에는 다음이 포함됩니다(제가 놓친 내용이 있을 수 있습니다).

  • 파일 이름(디렉토리 트리에 위치): 블록 장치, 문자 장치, 일반 파일, 디렉토리, 심볼릭 링크, 명명된 파이프, 명명된 소켓.
  • 순차적으로 읽기/쓰기 가능: 파이프, 소켓, 문자 장치, 블록 장치, 문자 장치, 일반 파일, 명명된 파이프, 명명된 소켓,
  • 무작위 액세스: 일반 파일, 블록 장치.

뭔가 놓쳤어 /proc, 뭔가 /sys, 뭔가 /net. 이 사람들은 다른 사람인 척합니다.

관련 정보