./unix/filesystem.txt

download original
unix filesystems:

- a file is a finite sequences of bytes with a specific length.

- an inode is a structure with meta data about a specific file. It
  contains:

  - user, group, r/w/x permissions for user, group, others

  - file size

  - pointer to file's content somewhere in the filesystem 

  - file type (regular file|directory|symlink|device file|socket|..)

  - link count (number of hard links (see below) currently pointing to
    the inode)

- (1) permission r: read file

- (2) permission w: write file

- (3) permission x on regular files (not directories): execute the
  file

- a directory is a file with fixed contents: a list of "directory
  entries"

- a directory entry is a (filename, inode number) tuple.

- an inode number is a pointer to an inode somewhere in the filesystem

- several directory entries (in the same or in different directories)
  having the same inode number (i.e. pointing to the same inode) are
  called hard links (actually every directory entry is a hard link)

- there is no support for having multiple inodes pointing to the same
  file contents

- as per (1), the r permission on a directory means you're able to
  read the directory's contents, i.e. the list of (filename, inode
  number) tuples

- as per (2), the w permission on a directory means you're able to
  write the directory's contents, i.e. the list of (filename, inode
  number) tuples (directory entries). This SHOULD mean that you should
  be able to rename files without being able to read their inodes or
  content -- but that's not the case TODO why? (removing (unlinking) a
  file requires write access to its inode to decrement the link count)

This means you can add/remove
  (link/unlink, actually) files from the directory -- even if you
  can't read and/or write those files themselves

- the x permission on a directory means you're able to read the inodes
  pointed to by the directory entries

  - this implies that if you have the r permission but not the x
    permission on a directory, you can read the directory entries
    (which contain the the file names), but you can't read the files'
    inodes (which contain the size, user, group, and permission bits):

    $ mkdir foo
    $ touch foo/bar foo/baz
    $ ls -ld foo
    drwxrwxr-x 2 olaf olaf 4096 Oct 17 18:35 foo
    $ ls -l foo
    total 0
    -rw-rw-r-- 1 olaf olaf 0 Oct 17 18:35 bar
    -rw-rw-r-- 1 olaf olaf 0 Oct 17 18:35 baz
    $ chmod -x foo
    $ ls -ld foo
    drw-rw-r-- 2 olaf olaf 4096 Oct 17 18:35 foo
    $ ls -l foo
    ls: cannot access foo/bar: Permission denied
    ls: cannot access foo/baz: Permission denied
    total 0
    -????????? ? ? ? ?            ? bar
    -????????? ? ? ? ?            ? baz
    $ 

  - creating a file requires wx on the directory (w to write the
    directory entry/file name, x to create the inode).

    Linking an existing file also requires wx on the directory (w to
    write the directory entry/file name, x to increment the link count
    in the inode).

    Reading a file with known name only requires x on the directory
    (presumably to read the point to the contents from the inode --
    but why doesn't it require r on the directory to get the inode
    number in the first place?) and r on the file. Since listing the
    file names in the directory requires r, having only wx on a
    directory means you can create a file in the directory, but you
    cannot see the files names in the directory (including the one you
    created) -- you can however (strangely) see a specific file name
    and its inode contents (size, permissions etc.) if you know its
    name, even though you shouldn't be able to get at the inode number
    in the directory because of the missing r??

- the sgid bit on a directory means that if a file is created[*] in
  the directory, that file's group is set to the directory's group

- the suid bit on a directory is ignored (except on FreeBSD, where it
  it trated analogously to the sgid bit, but it pertains to the user
  rather than the group)



TODO:

- path search permissions, path_resolution(7)

- symlinks

-
back to unix