Operating Systems 2017F Lecture 20

From Soma-notes
Revision as of 20:32, 28 November 2017 by Soma (talk | contribs)

Video

Class Video

Notes

In Class

Lecture 20
----------

When we run "ls" on an sshfs-mounted filesystem
* ls makes system calls (open, getdents) to the local Linux kernel
* the local kernel sees filesystem is FUSE, calls FUSE routines for open, getdents (via vfs abstraction)
* FUSE calls the sshfs process that mounted the filesystem
* sshfs process sends request to remote system
  - via socket system calls
* remote sshd process receives request (via system calls)
* remote sshd process accesses local filesystem
  - makes open, getdents system calls
  - remote kernel checks vfs, calls ext4 routines to access data
* remote sshd process responds to request (via system calls)
* local sshfs process receives response (via system calls)
* local sshfs process responds to FUSE request
* FUSE passes data back to vfs layer, then back to requesting process

Normal file access permission check
 - compare uid, gid of file with uid, gid of process

But really...
 - compares it with fsuid, fsgid of process
    - which is normally same as euid, egid of process

Additional Notes

Assignment 4 will be autograded and in fill in the blank form. This will not be like the final exam.
You should think about who is doing what? Otherwise FUSE won't make much sense

Inode numbers completely changed when you use ssh. It starts with 1 from "." (root) and increments from there.
Inodes come from filesystem you are acessing
He used df to find filesystem info
The used Commands: mount | grep ubuntu and mount | grep vda1 to find type of filesystem
In the SSH there is the filesystem type "fuse.sshfs"
When you run strace on ls on the two terminals (ssh connection and the local one) you see similar output
When we run "ls" on an ssh-mounted filesystem

  • ls makes system calls (open, getdents) to the local Linux kernel
  • the local kernel sees the filesystem is FUSE, calls DUSE routines for open, getdents (via vfs abstraction)
  • FUSE calls the sshfs process that mounted the filesystem
  • sshfs process sends request to remote system

- via socket system calls

  • remote sshd process receives request (via system calls)
  • remote sshd process receives requests (via system calls)

- makes open, getdents sytem calls
- rmeote kernel checks vfs, calls ext4 routines to access data

  • remote sshd process responds to requests (via system calls)
  • local sshfs process receives response (via system calls)
  • local sshfs process responds to FUSE request (via system calls)
  • FUSE passes data back to vfs layer, then back to requesting process


If you look as lsmod | less you see a ton of modules. Some of the modules are not necessary to mount the root filesystem.
ls /lib/modules there are directories that store the kernel modules
You have to have a filesystem that you mount initially that has a bunch of modules in it. Thus, there is an initial root file system that is necessary to load everything else
This is the initial RAM disk. This filesystem loads the modules needed for the real filesystem.
To remove a file I need to remove the hardlink from the directory where the hardlink exists
The password files maps usernames to user id's (Linux does not care about your username)
Normal file access permission check br> - compare uid, gid of file with uid, gid of process
But really:
- compares it with fsuid, fsgid of process
- which is normally same as euid, egid of process