모든 유닉스 계열 시스템에서 정보들은 기본적으로 "/" 루트 파일 트리에 저장된다. 파일 트리는 디렉토리들의 계층적 집합으로 디렉토리 각자가 파일시스템 객체 (FSO) 를 포함할 수도 있다.
리눅스에서 파일시스템 객체는 보통의 파일, 디렉토리, 심볼릭 링크, 네임드 파이프 (선입 선처리, FIFO, first-in first-out 이라고도 부른다) , 소켓 (밑부분을 보라), 문자 디바이스 파일 또는 블록 디바이스 파일일 수 있다 (이 목록은 find(1) 명령으로 볼 수 있다). 다른 유닉스 계열 시스템도 동일한 또는 유사한 FSO 타입 목록을 갖는다.
파일시스템 객체는 파일 트리에 디렉토리로 마운트 및 언마운트될 수 있는 파일시스템에 모아진다. 파일시스템 타입 (예, ext2 와 FAT) 은 속도, 신뢰성 등을 최적하기 위해 디스크상에 데이터를 배열하기 위한 특정한 일련의 합의이다; ``파일시스템"은 ``파일시스템 유형" 과 동의어로 사용된다.
여러가지 유닉스 계열 시스템은 다양한 파일시스템 타입을 지원한다. 파일시스템은 약간 다른 일련의 접근 제어 속성들을 가질 수 있으며 접근 제어는 마운트시 선택한 옵션에 의해 영향을 받을 수 있다. 리눅스에서는 ext2 파일시스템이 현재 가장 널리 사용되고 있으며 리눅스는 방대한 양의 파일시스템을 지원하는데 대부분의 유닉스 계열 시스템도 다중 파일시스템을 또한 지원한다.
유닉스 계열 시스템에서 대부분의 파일시스템은 적어도 다음을 저장한다:
소유 UID 와 GID - 파일시스템 객체의 ``소유자"를 식별한다. 달리 언급되지 않는다면 소유자 또는 루트만이 접근 제어 속성을 변경할 수 있다.
허가권 비트 (permission bits) - 각 사용자 (소유자), 그룹 및 other 에 대한 읽기, 쓰기 및 실행하기 비트. 일반 파일에 대해서는 읽기, 쓰기와 실행하기는 일반적인 의미를 갖는다. 디렉토리에서 ``읽기" 허가권은 디렉토리의 내용들을 표시하기 위해 필요하며 반면 ``실행하기" 허가권은 때로는 ``검색 (search)" 허가권이라고도 하는데 그 내용들를 사용하기 위해 실제 디렉토리내로 들어가기 위해 필요하다. 디렉토리에서 ``쓰기" 허가권은 그 디렉토리내에 파일 추가하기, 제거하기 및 재명명하기를 허용한다; 단지 추가하기만을 허용하려면 밑부분에 언급되는 sticky 비트를 설정해라. 심볼릭 링크에 대해서는 허가권 값이 전혀 사용되지 않음을 주목해라; 중요한 것은 단지 이들이 포함하는 디렉토리와 링크된 파일의 값이다.
``sticky" 비트 - 이 비트가 디렉토리에 설정되어 있을 때 그 디렉토리내에서 파일의 언링크 (제거) 및 재명명은 파일 소유자, 디렉토리 소유자 또는 루트만이 할 수 있다. 이는 매우 공통된 유닉스의 확장으로 오픈 그룹의 Single Unix Specification 버전 2 에 명시되어 있다. 초기 유닉스 버전들은 이를 ``save program text" 비트라고 불렀으며 이를 메모리에 상주해야 하는 실행가능한 파일을 가리킬 때 사용하였다. 루트만이 이 비트를 설정할 수 있도록 시스템은 보증했는데 그렇지 않다면 사용자들이 억지로 ``모든 것"을 메모리에 올림으로써 시스템을 파손시킬 수 있을 것이다. 리눅스에서 이 비트는 일반 파일에 아무런 영향을 미치지 않으며 일반 사용자는 자신이 소유한 파일에 대해 이 비트를 변경할 수 있다: 리눅스의 가상 메모리 관리 기법은 이러한 비트를 사용해도 아무런 문제가 되지 않게 한다.
setuid, setgid - 실행가능한 파일에 설정되어 있을 때 이 파일을 실행시킴으로써 프로세스의 유효 UID 또는 유효 GID 는 각각 파일 소유 UID 또는 GID 로 설정될 것이다. 모든 유닉스 계열 시스템은 이를 지원한다. 리눅스와 System V 에서 실행 권한이 없는 파일에 setgid 가 설정되어 있을 때 이는 접근 도중 강제 로킹 (mandatory locking) 되는 파일을 가리킨다 (파일시스템이 강제 로킹을 지원하도록 마운트된 경우); 이렇듯 많은 의미는 많은 사람을 놀라게 하는데 유닉스 계열 시스템에서 보편적인 것은 아니다. 사실 chmod(3) 에 대한 오픈 그룹의 Single Unix Specification 버전 2 는 이러한 설정이 의미가 없는 경우 실행불가능한 파일에 대해 setgid 을 설정하는 요청을 시스템이 무시할 수 있도록 한다. 리눅스와 솔라리스에서 디렉토리에 setgid 가 설정되어 있을 때 이 디렉토리내에서 생성된 파일의 GID 는 디렉토리의 GID 로 자동 설정된다. 이러한 접근방법의 목적은 ``프로젝트 디렉토리"를 지원하기 위한 것으로 사용자들은 파일을 이렇게 특별히 설정된 디렉토리에 저장할 수 있으며 그룹 소유자는 자동적으로 변경된다. 그러나 디렉토리에 setgid 를 설정하는 것은 SiIngle Unix Specification [Open Group 1997] 과 같은 표준에는 명시되어 있지 않다.
타임스탬프 - 각 파일시스템 객체에 대해 접근 및 변경 시간이 저장된다. 그러나 소유자는 이 값을 임의로 설정할 수 있기 때문에 (touch(1) 을 보라) 이러한 정보의 신뢰성에 유의해라. 모든 유닉스 계열 시스템은 이를 지원한다.
다음 속성은 ext2 파일시스템에서 리눅스 고유의 확장이다. 물론 많은 다른 파일시스템도 유사한 기능성을 갖는다:
immutable (불변) 비트 - 파일시스템 객체에 대한 어떠한 변경도 허용되지 않는데 단지 루트만이 이 비트를 설정 또는 제거할 수 있다. 이는 단지 ext2 만 지원하며 모든 유닉스 시스템 (또는 모든 리눅스 파일시스템) 에 대해 이식가능한 것은 아니다.
append-only 비트 - 파일시스템 객체에 덧붙이기만 허용되는데 단지 루트만이 이 비트를 설정 또는 제거할 수 있다. 이는 단지 ext2 만 지원하며 모든 유닉스 시스템 (또는 모든 리눅스 파일시스템) 에 대해 이식가능한 것은 아니다.
다른 공통된 확장은 ``이 파일을 삭제할 수 없다" 를 가리키는 어떤 종류의 비트들을 포함한다.
이러한 값들중 많은 것들은 마운트시 영향을 받을 수 있으며 따라서 예를 들면 어떤 비트는 일정한 값 (미디어상에서 그들의 값에 상관없이) 을 갖고 있는 것처럼 처리될 수 있다. 이에 대해 더욱 자세한 정보는 mount(1) 을 보라. 이러한 비트들은 유용하지만 이들중 일부는 손쉬운 사용을 간단히 하기 위한 것으로 실제로 어떤 행동을 예방할 만큼 충분하지 않음을 알고 있어라. 예를 들어 리눅스에서 ``noexec" 옵션을 갖고 마운팅을 하는 것은 그 파일시스템에서 프로그램의 실행을 금지할 것이다; 메뉴얼에 언급된 것과 같아 이는 호환되지 않는 시스템에 대해 바이너리를 포함하고 있는 파일시스템을 마운팅하기 위한 것이다. 리눅스에서 이 옵션이 파일 실행을 완전히 막지는 못할 것이다; 파일을 실행시킬 수 있는 다른 어딘가에 이를 복사할 수 있으며 또한 이 파일을 직접적으로 실행시키기 위해 ``/lib/ld-linux.so.2" 명령을 실행시킬 수도 있다.
어떤 파일시스템들은 이러한 접근 제어 값들중 일부를 지원하지 않는다; 이러한 파일시스템이 어떻게 다뤄지는 가에 대해서는 mount(1) 을 보라. 특히 많은 유닉스 계열 시스템은 MS-DOS 디스크를 지원하는데 MS-DOS 디스크는 이러한 속성들을 거의 지원하지 않는다 (이러한 속성을 정의하는 표준 방식은 없다). 이런 경우 유닉스 계열 시스템은 표준 속성을 에뮬레이트하며 (특별한 디스크상의 파일을 통해 될 수 있는한 이들을 구현함으로써) 이러한 속성은 일반적으로 mount(1) 명령에 의해 영향을 받는다.
유닉스 계열 시스템이 보다 복잡한 체계 (POSIX ACL) 을 지원하지 않는다면 파일 추가 및 제거를 위해서는 파일의 디렉토리 허가권 비트와 소유자만이 중요하다는 것을 언급하는 것은 중요하다. 시스템이 다른 확장을 갖고 있지 않다면, 리눅스 2.2 는 이를 지원하지 않는데, 허가권 비트가 설정되지 않은 파일은 파일을 포함하는 디렉토리가 제거를 허용한다면 제거될 수 있다. 또는 조상 디렉토리가 자손에게 어떤 사용자 또는 그룹에 의해 변경되도록 허용한다면 그 디렉토리의 모든 자손은 그 사용자 또는 그룹으로 대체될 것이다.
보안에 대한 IEEE POSIX 표준 초안은 허가권을 갖는 사용자와 그룹 목록을 지원하는 표준에 일치하는 ACL 에 대한 기법을 정의하고 있다. 불행히 이는 널리 지원되지 않으며 유닉스 계열 시스템에 동일한 방식으로 지원되지 않는다. 예를 들어 리눅스 2.2 는 파일시스템내에 ACL 또는 POSIX 능력 값을 갖고 있지 않다.
리눅스 ext2 파일시스템이 루트 사용자를 위해 소량의 공간을 남겨두고 있음을 언급하는 것은 가치가 있다. 이는 서비스 부인 공격에 대한 부분적인 방어로 사용자가 루트 사용자와 공유하는 디스크를 가득 채운다고 할지라도 루트 사용자는 중대한 기능을 위해 소량의 공간을 갖는다. 디폴트는 파일시스템의 5% 로 mke2fs(8) 특히 "-m" 옵션을 보라.
생성시 다음 규칙이 적용된다. 대부분의 유닉스 시스템에서 create(2) 또는 open(2) 에 의해 새로운 파일시스템 객체가 생성될 때 FSO 의 UID 와 GID 는 각각 프로세스의 UID 와 GID 로 설정된다. 리눅스는 FSUID 확장때문에 약간 다르게 작동하는데 FSO 의 UID 와 GID 가 각각 프로세스의 FSUID 와 FSGUID 로 설정된다; 파일을 포함하는 디렉토리의 setgid 비트 또는 파일시스템의 ``GRPID" 플래그가 설정되어 있다면 FSO GID 는 실제적으로 그 디렉토리의 GID 로 설정된다. 썬 솔라리스와 리눅스를 포함한 많은 시스템들은 또한 setgid 디렉토리 확장을 지원하는데 앞에 언급했듯이 이 특별한 경우는 ``프로젝트" 디렉토리를 지원한다; ``프로젝트" 디렉토리를 만들기 위해서는 그 프로젝트에 대한 특별 그룹을 생성하고 그룹 소유의 프로젝트를 위한 디렉토리를 생성한 후 디렉토리에 setgid 비트를 설정해라: 이 디렉토리에 놓인 파일은 자동적으로 프로젝트에 의해 소유된다. 비슷하게 새로운 디렉토리가 setgid 비트가 설정된 (파일시스템 GRPID 는 설정되어 있지 않다) 디렉토리내에서 생성된다면 새로운 하부 디렉토리도 setgid 비트가 설정되어 있을 것이다. 따라서 프로젝트 하부 디렉토리도 비슷하게 사용할 수 있다: 모든 다른 경우에 있어서 setgid 비트는 새로운 파일에 대해 제거된다. 이는 ``사용자-개인 그룹 (user-private group)" 체계에 대한 논리적 근거로 레드햇 및 다른 배포업자가 사용하고 있는데 모든 사용자는 단지 자신을 멤버로 갖는 "개인" 그룹의 멤버이며 따라서 디폴트로 그룹에게 파일 읽기와 쓰기 권한을 허용할 수 있다 (자신의 그룹의 멤버이기 때문에). 따라서 파일의 그룹 멤버십 이런 방식으로 전달될 때 읽기와 쓰기 권한도 또한 전달된다. FSO 기본 접근 제어 값 (읽기, 쓰기, 실행하기) 은 요청값과 프로세스의 umask 논리곱으로부터 계산된다. 새로운 파일은 늘 sticky 및 setuid 비트가 없이 시작된다.
chmod(2), fcmod(2) 또는 chmod(1) 을 이용하여 이러한 속성값의 대부분을 설정할 수 있는데 또한 chown(1) 과 chgrp(1) 을 보라. 리눅스 고유의 속성중 일부는 chattr(1) 을 이용하여 조작된다.
리눅스에서는 단지 루트만이 주어진 파일의 소유자를 변경할 수 있음을 주목해라. 어떤 유닉스 계열 시스템은 일반 사용자가 그들의 파일 소유권을 다른 사용자에게 전달할 수 있도록 하는데 이는 문제를 복잡하게 하며 리눅스에서는 금지되어 있다. 예를 들어, 디스크 사용을 제한하려고 하는 경우 파일 소유권 변경을 허용한다면 사용자들은 임의의 커다란 파일은 실제로 다른 사용자의 것이다라고 항의를 할 것이다.
리눅스와 대부분의 유닉스 계열 시스템하에서 읽기와 쓰기 속성값은 파일이 열려질 때만 검사된다; 물론 모든 읽기 또는 쓰기에 대해 재검사되지는 않는다. 파일시스템은 유닉스 계열 시스템의 중심이기 때문에 아직도 많은 수의 호출이 이러한 속성을 검사하는데 이러한 호출로는 open(2), create(2), link(2), unlink(2), rename(2), mknod(2), symlink(2) 및 socket(2) 들이 있다.
다년간에 걸쳐 어떤 파일은 어느 곳에 놓아햐 한다는 합의가 확립되어 왔다. 가능한 계층구조에 정보를 놓을 때 합의된 사용을 따르기 바란다. 예를 들어, 전체적인 설정 정보는 /etc 디렉토리밑에 놓아라. 파일시스템 계층구조 표준 (Filesystem Hierarchy Standard, FHS) 는 논리적 방식으로 이 합의를 정의하려고 하며 리눅스 시스템에 널리 사용되고 있다. FHS 는 리눅스, BSD와 시스템 V로부터 얻어진 교훈과 접근방법을 병합한 이전 리눅스 파일시스템 구조 표준 (Filesystem Structure Standard, FSSTND)의 갱신이다. FHS 에 대한 더욱 자세한 정보는 http://www.pathname.com/fhs 를 보라. 이러한 합의의 요약은 리눅스와 솔라리스에 대해 각각 hier(5) 와 hier(7) 에 있다. 때때로 서로 다른 합의가 일치하지 않는데 가능한 이러한 상황은 컴파일 또는 설치시에 설정할 수 있도록 해라.
저자는 FHS 가 리눅스 배포판들간의 호환성 증대 및 소프트웨어 애플리케이션이 호환되는 리눅스 시스템에서 작동할 수 있도록 일련의 표준을 개발 및 촉진하는 Linux Standard Base에 의해 채택되었음을 특히 언급한다.