Operating Systems 2017F Lecture 20

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

Sshfs

• Inode values are different in remote vm vs local vm
  
• Values increment from 1 in local vm
  
• Who's supplying the inode values?
  
  • Ext4 filesystem in local vm
    
  • Fuse.sshfs filesystem in remote vm
    
• Filesystem determines the interpretation of inode values
  
• Inodes have no meaning outside its filesystem
  
• Local to its filesystem => hardlinks are different too
  
• "strace ls" in both output the same thing
  
• Vfs not built into original unix filesystems
  
• Try "strace"ing the sshfs call, see how its interacts with fuse
  
• Don't need to know exact system calls, but you should know when it has to make system calls and why
  
  • Needs to access files over the network
    
• Understand why you can't do this with regular library calls
  
• Removing the root filesystem will trigger a kernel panic
  
  • Kernel will prevent you from unmounting filesystems that contain other filesystems
    
• Kernel modules located in "/lib/modules/"
  
• Initial filesystem is loaded into kernel
  
  • Fake filesystem, throw away after loaded, not persistent
    
  • Ram disk = filesystem stored in ram
    
  • Gets the system up to the point where the kernel can load the real filesystem
    
  • Bootloader has to load both kernel and the initial ram disk into ram
    
  • Ram disks located in "/boot = initrd.img<...>"
    
  • Kernel version specific
    
  • Generated as part of installation of kernel
    
• Cpio: copies files to and from archives
  

• What determines whether you can access a file?
  
  • The filesystem
    
• How to map from user id to username?
  
  • Recall that
    

- Kernel knows nothing about usernames
- This is a userspace process
- Looks in local password file

• What determines whether an operation is allowed?
  
  • Checks to see who owns the file
    
  • Compare uid, gid of file with uid, gid of process
    
• In remote system, sftp does file access checks