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
  

ADDITIONAL NOTES:

Fuse: makes you think who is doing what?  How it is connected in the kernel .  Fuse.sshfs : is what chose the inode numbers? o Can they be identical to the other inode numbers?  Yes but why?  What the process of getting the directories? The inodes come from the filesystem which you are accessing

Who chose the inode number: the filesystem determine the intereprtation of an inode number, Inode is local to a filesystem. How is the kernel obtaining information? : Fuse : has three kinds 1) Fuseblk 2) Fuse 3) Fusectl Summary of sshfs: Sshfs process that has to make system call to talk to the network to the remote system. Similar to a web request , but the difference separate from that we have a different system calls which is the ls process. To do this, the kernel must call a process. Does sshfs create 2 processes? Yes , it actually creates multiple of process The remote kernel prespective : file accessing files and sending data back to another system. Remote data is not doing anything special.

• To verify : ps aux | grep ssh

To learn system call sshfs doing ,running local strace as much as you can. You can mount a file system which would not allow you to mount any further When you update the kernel : the initial ram disk will not be update since it is redundant, it will generate it. Can we mount a filesystem in a file?

What is suspicious? A lot of repetitive inodes 3rd column : amount of hard links. Avoid multiple of binaries if you want a small system, you just need the basics. After mounting it it loads the linux system. Permissions: the owner can change these permissions, but you can’t take away your own privileges. 1) Removing a file : unlinking the file, removing a hardlink which modifies the directory in which a hardlink exists. Why do I have the permission to remove it? 2) Create a file : ouch afile, ls –la afile, Premissions: 1) Other 2) User 3) Group 4) Files system has EUID( very important because processes can run as a user but have permissions of another user ) AND GID: permissions what you have and fs is what ur system sees Minix system which manages your CPU. Busy Box : One binary to pretend it is different programs and we also have a program which pretends to be many. Give it hard link to different names. Soma vs anilclass: anil class is special account. The current directory is owned by soma so how did anilclass was able to create a file? Filesystem understands those primission checks? (prof is not sure about this fact and will check it) Map a user ID to your user name? it’s a user space problem, kernel doesn’t care about the username. By looking at the password file : grep 1000 /etc/passwd. Where are the permissions done in sshfs? (in the steps

• sftp search process which will determine the permissions. remote file system and the remote kernel (ext4) will check via sftp. All the file access (grabbing the files)

Verify : ps aux | grep sftp Who started this sftp: the sshd did.

Commands: Mount | grep “name” Strace ls : directories look the same although they are mounted since ls can not tell , ls is not doing anything differe just opening ur directory and getting data there Man sshd : run it and give it aport like 222. Easiest way is using 2 machines on open stack and terminal. It is a good exercise Initial Ram disk : to get the real root system to be mounted , similar to memory ll. Sudo mount initrd.img-4.10.0-40-generic /mnt : to mount a file in a file system but it didn’t not work and there is an alternative way of doing this Anther way : man CPIO : copy files to an form archives . ex : TAR CPI - - help : to figure it out Ls –a bin | less Cd \ boot : RAM disk Du –s –h : in this case (121mb) to see the size of the busy box but the modules takes up half of that space. Ls –lai | head Chmod a-w : you are unable to write to this directory anymore Chmod o+w : granted permission to other…. Ls –la /bin/fusermount Who gives us premissions: just does a normal open and read , the remote kernel enforces these premissions.

Lecture 20

$ ls -lai less

• inode numbers are completely different -> they are determined by the filesystem
• an inode has no meaning outside its fs; it's local to the fs

What's the filesystem?

• $ df .
• $ mount | grep vda1

Find fuse fs:

• $ cat /roc/filesystems | grep fuse

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

• $ ps aux | grep sshfs

• sshfs is itself a process that has to make system calls to talk over the network to the remote system
• sshfs process sends request to the 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

• Initial ramdisks - Tue 28 Nov 2017 13:44:34 EST

• bootloaded loads both the kernel and initial ramdisk into RAM on boot
• /boot -> initrd. = ramdisk

• $ du -s -h asdf/asdflkj/gkgk
• $ du -s -h .

Display a pid's euid

• $ ps -eo pid, euid | grep YOUR_PID_HERE
• $ ps -eo pid, euid, ruid, suid | grep YOUR_PID_HERE

List mounts:

• $ mount -l
• $ df -aTh

SSHFS "Writing a FUSE FS: A tutorial"