Operating Systems 2014F: Assignment 9

Please submit the answers to the following questions via CULearn by just before class (8:30 AM) on Friday, December 5, 2014. There 10 points in 5 questions.

Submit your answers as a single text file named "<username>-comp3000-assign9.txt" (where username is your MyCarletonOne username). The first four lines of this file should be "COMP 3000 Assignment 9", your name, student number, and the date of submission. You may wish to format your answers in Markdown to improve their appearance.

No other formats will be accepted. Submitting in another format will likely result in your assignment not being graded and you receiving no marks for this assignment. In particular do not submit a zip file, MS Word, or OpenOffice file as your answers document!

Don't forget to include what outside resources you used to complete each of your answers, including other students, man pages, and web resources. You do not need to list help from the instructor, TA, or information found in the textbook.

1. [2] A friend says to you that "a loopback mount over sshfs makes it easy to temporarily share files between users without changing file permissions." Explain what your friend is saying, explaining a "loopback mount" and how they interact with file permissions. (Note you may see some weird behavior!)
2. [2] How do processes find out that an authentication agent (ssh-agent or similar) is running and will accept connections from them? How would you expect this information to be propagated between applications?
3. [2] Can sshfs directly control filename to inode mappings on the remote system (that is being mounted)? Explain briefly.
4. [2] How many background processes does mounting a remote filesystem over sshfs create on the client? What do each of them do?
5. [2] If you kill the ssh-related processes on the server (without touching those on the client) while a filesystem is mounted via sshfs, what happens to that filesystem? Why? (Describe the behaviour and give a basic explanation for it.)

Solutions

1. The friend is saying that you can do an sshfs mount to localhost, e.g., "sshfs other@localhost: other-files" and all of the files of user other will appear in the directory other-files. You can then copy files back and forth between these two users without having to do any file permission modifications, because the files of the other user can now all be accessed and changed, just as they can be accessed and changed by the other user when they are logged in. The weird part of this is if you look at the owner and group of the files in other-files you will see that they are in fact still "owned" by the other user. A strict interpretation of the file permissions would make one think these files are NOT accessible, when in fact they are. It turns out sshfs by default just fills in the user and group from the remote system even though they essentially have no meaning locally. Access to files is determined on the remote side, not locally, so the spurious information doesn't actually change how things behave. They are just confusing. (There are options to sshfs that allow the user and group of files to be mapped to other values.)
2. Processes check their environment variables for the SSH_AUTH_SOCK variable. If this exists, its value contains information on how to connect to the user's authentication agent. This environment variable is propagated as all environment variables are, from parent to child processes and as arguments to execve system calls.
3. sshfs cannot control the file to inode mappings on the remote system because it can only do what regular processes on the remote system can do (i.e., the remote sftp-server process). Processes cannot directly specify inodes to file operations because doing so could allow file access controls to be bypassed (e.g., accessing a world-readable file inside of a private directory). Having said this, sshfs *must* specify the file to inode mappings locally (on the host running sshfs), as this is a key part of implementing a filesystem. The locally specified inode numbers are completely arbitrary and have nothing to do with the specific inodes on the remote system, to the point that hard linked files on the remote system have different inode numbers.
4. sshfs creates two processes on the local (mounting) machine: an sshfs process and an ssh one. The sshfs process takes care of the FUSE part, i.e., it implements the actual filesystem semantics for the kernel. The ssh process communicates with the remote system, handling the transfer of data back and forth.
5. If you kill any of the sshfs-related processes on a remote system they all terminate, as they are all highly dependent upon each other. Their termination closes the network connection, causing the local ssh process to terminate. The sshfs process notices that ssh has terminated and then itself terminates after releasing the mountpoint (doing the equivalent to fusermount -u). After all of this the sshfs filesystem is no longer mounted. If any process accessing files or directories under the mountpoint they will get errors such as "Transport endpoint is not connected"; new accesses to the mountpoint will just see it as an empty directory (FUSE doesn't normally allow the use of non-empty directories as mountpoints).