Changes between Initial Version and Version 1 of FixingLiblocker


Ignore:
Timestamp:
07/24/09 01:30:48 (12 years ago)
Author:
broder
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • FixingLiblocker

    v1 v1  
     1== Overview == 
     2 
     3With the introduction of PyHesiodFS, a lot of the traditional functionality of `liblocker` and programs that use it (`attach`, `detach`, `add`, `quota`, `fsid`, `zinit`) is no longer necessary, and in fact, actively detrimental to smooth locker interactions. We'd like to replace the C library and programs with a more maintainable Python package and Python scripts, also using this as an opportunity to prune outdated, unused, or unnecessarily complex functionality. In general, '''the responsibility of tracking state should fall to PyHesiodFS''', while `liblocker` should only be responsible for those operations which can't be performed from the filesystem. 
     4 
     5For example, `liblocker` currently uses an `attachtab` (stored in `/var/run/attachtab` on Debathena machines) to track which lockers have been attached by which users. Instead, `liblocker` should simply list the contents of `/mit`; since PyHesiodFS provides a view of `/mit` that is unique per-user, `ls /mit` will only show those filesystems which have been mounted by the current user. 
     6 
     7On the other hand, `attach` has traditionally been responsible for subscribing the user to zephyr notifications for the fileserver of filesystems being mounted, or acquiring the credentials needed to access a filesystem. Because of OS-level privilege separations, it's not possible for PyHesiodFS to do either of these things, so they must still be handled by `attach` 
     8 
     9== Related Tickets == 
     10 
     11#227, #228, #202 
     12 
     13== attach.conf == 
     14 
     15Much of `/etc/athena/attach.conf` is currently being used to limit the set of directories on which `attach` will operate. Post-revision, `liblocker` and its utilities will only operation on first-level subdirectories of `/mit`, so this configuration is not necessary. Any necessary filesystem configuration (such as NFS mount options) will be handled by PyHesiodFS or off-loaded (e.g. to an autofs `/net` automounter). 
     16 
     17`/etc/athena/attach.conf` is no longer needed. 
     18 
     19== attach == 
     20 
     21In its most basic form, `attach` in an automounted world simply consists of a call to `stat(2)`. However, we also want to preserve more advanced usage of `attach`, so most of the current functionality of `attach` should be retained. 
     22 
     23Explicit mountpoints/targets can be created using `os.symlink` (using `os.rmdir` may be necessary if the mountpoint already exists). These mountpoints no longer require root privileges to create. 
     24 
     25Finally, the following options from the `attach` manpage should be dropped: 
     26 
     27`--master` (`-M`), `--mountoptions` (`-o`), `--nosetuid` (`-nosuid` or `-N), `--setuid` (`-suid` or `-S`), `--override` (`-O`) 
     28 
     29== detach == 
     30 
     31As with `attach`, `detach` can mostly be expressed as a single syscall: `unlink(2)` (i.e. `os.remove`). Since all operations against PyHesiodFS only affect the current user, no operations require privilege. 
     32 
     33The following options to `detach` can be dropped; all others should be preserved: 
     34 
     35`--override` (`-O`), `--clean` (`-C`)