Lecture 12 File System Implementation

Multiple Filesystems

• Boot, usr, home, etc. are all individual filesystems. Swap is for vitual memory.

Hierarchy

The layers of a Unix file systems (from lowest to highest level):

Sectors

• Traditionally 512 bytes

• Now slightly bigger, but still fairly small

Blocks

• E.g. 8 KiB each

Partitions

• Each partition can have a different purpose

• Can break into partitions however they like

• A lot of partitions or file system directories in a home laptop or desktop because it's to limit the damage caused by filling up a file system

  • Once a file system is filled up, no user can get anywhere

File Systems and Mounts

• mount("/etc/foo", "/dev/rst/03")

  • Fails if /dev/rst/03 is already mounted except for loopback mounts (must worry more about loops)

• The following are examples of hierarchy between filesystems:

  
  
  

Inodes

• Use object oriented programming to support file systems

• API for file systems code

• File systems is an object

• VFS layer is an object oriented implementation in C

• File types

  type               symbol

  directory          d

  Regular File       -

  Symbolic link      l

  File               p

  Character special  c

  Block special      b

  contiguous file    C

File Name Components

• File name resolution

• open("abc/def/ghi")

  • These directories & file need search permission

• Loopover file have current directory + file name component

• Current directory = inode number for that file

• If multipile files => current directory have device number as well as inode number

• If "def" is missing => error = ENOENT

  • No such file or directory

• If no permission => error EPERM

• Root directory

  • cholir

  • chroot

    • What if chroot could be executed by non-root users? The root directory could be attacked using the method below:

      $ chroot /home/eggert/playpen
$ su
Password: eggert
#
      

    • chroot("/..") = chroot("/") = noop

    • Makes current directory a root so nothing can go outside of it

    • Can make files go invisible, which is problematic

    • "chrooted jail"

      • Root can create coprod (contains apache)

      • Apache is full of holes. If we put it in a chrooted jail, then we can limit the scope of the damage.

        

File Names

• Also known as pathnames.

Symbolic Links

• Anyone can read symlink, nobody can write to symlink

• Pros:

  • Can access file system boundaries

  • Can link to a directory

  • Can link to a nonexistent file

• Cons:

  • Can loop

  • Can take an amount of time bounded by the number of inodes to find this loop

• dev/null

  • All file systems must have this

  • If this doesn't exist, the file system cannot discard any unwanted outputs of processes

• dev/full

  • Whenever anyone tries to write to it, it says it's full

• dev/zero

  • Throws away anything we write, only puts zero's

• Hardlinks (compared to symlinks)

  • Hardlinks will not map to nonexistent files.

  • Hardlinks can't loop.

  • Hardlinks will complicate the user model.

  • No need for directory entries.

• lstat("foo", &st)
stat("foo", &st)
readlink("b", buf, bufsize)

  • If foo is a symlink, lstat will fill st with symlink information. Lstat doesn't follow symlinks.

    Stat is similar to lstat. Lstat will return information about the file the link references.

    Readlink reads the value of the symlink.

Intentionally Making Bad Data

If we want to prevent an attacker from accessing sensitive data, we can:

• Use the chmod 0 command?

  • No, because the attacker could simply use the chmod 444 command to undo.

• Use the rm command?

  • No, because the attacker could read the data directly from the sector.

• Use the shred command?

  • No, because the command does not actually check to see if the file is completely gone. All it does is overwrite and flush repeatedly without actually knowing if it overwriting the sensitive data. Additionally, if there is built in redundancy in the file system (such as RAID), shred may not remove those copies completely.

• Use shred /dev/dsk/03?

  • Yes, as it will erase entire partitions, ensuring that every block is filled with garbage data. However, this process is extremely slow.

• Encrypt the file system and throw away the key?

  • Yes, if the file system is protected by an encryption algorithm with a sufficiently strong passphrase, then the contents on the disk will be effectively meaningless unless the key is known. Thus, the contents of the drive can be "erased" very rapidly if the key is destroyed or forgotten.

• Melt the device