Extended restricted filesystem to support relative paths.

documentation/filesystem_access.txt

 # Safe filesystem access
 
 ## Background
 
 Native Client is a useful library for restricted code execution that is useful
 beyond the browser. There’s all sorts of cases where one might want to run
 untrusted code in a system disconnected from Chromium or PPAPI.
 
 In these cases, it is additionally useful to allow restricted filesystem
 access, but to still run untrusted code.
 
 ## Constraints
 
 These constraints are NOT GUARANTEED TO BE ENFORCED BY SEL_LDR, and must
 be guaranteed by the caller:
  * The mounted directory is assumed to not include any symlinks.
 
 These constraints will be enforced by sel_ldr:
- * Pathnames must be absolute. Relative pathnames are explicitly disallowed.
  * Pathnames may not include the substring "..".
  * Access to filesystem within sel_ldr will behave as if as if the mounted
    directory is root.
 
 ## Requirements
 
  * Very low overhead File I/O.
  * Give users the ability to have selective read-only or read/write access.
  * Give users control over the entire filesystem layout presented to the
    untrusted application.
 
 ## Feature user experience
 
 This feature adds one additional commandline argument `-m` to `sel_ldr`. `-m`
 takes a path to the directory to be used as the root by the untrusted
 application.
 
 All of the given requirements can be satisfied by this `chroot`-style
 interface:
 
  * The only overhead for file I/O is in adding (and sanitizing) a path prefix
-   to absolute paths passed through to the host.
+   to absolute paths passed through to the host, or the cwd to relative paths
+   passed through to the host.
  * Read-only or read/write access can be controlled using normal filesystem
    permissions for the user running the `sel_ldr` process.
  * Using host-side filesystem primitives such as Linux bind mounts, users can
    map disparate paths from the host into the untrusted process's root.
 
 ## Implementation
 
 For the most part, this feature is simple and relatively straightforward to
 add. When `-m` is given (even if `-a` is not), file operations will be enabled
 and the provided chroot path will be added as a path prefix to all absolute
@@ skipping 12 matching lines @@
  * `rename`
  * `chmod`
  * `access`
  * `utimes`
 
 ### Path sanitization
 
 Path sanitization happens through a three stage process:
 
 1) Ensure the user's path is absolute.
+   If the user's path is relative, transform it to be absolute by prepending
+   the cwd. This requires that the cwd is within the mounted directory.
 2) Prefix the path to the mounted directory.
 3) Ensure that the path does not contain "..".
 
 ### Symlinks
 
 Ideally, symlinks should behave as if we had just chrooted into the path given
 to `-m` (which means they would resolve relative to the untrusted root).
 
 However, it's not straightforward to have `sel_ldr` call `chroot` itself to
 make the kernel do appropriate symlink resolution in a cross-platform way. So
@@ skipping 33 matching lines @@
 
  * `getdents` - `..` might reference an inode outside of the untrusted
    root, but that's okay because the untrusted application can't do anything
    with it.
  * `fstat` - no different than `stat`, which is already allowed.
 
 For both of these calls, we might need to make sure there's no file descriptors
 in the untrusted application that reference files outside of the untrusted
 root, but even if we don't there's very little the untrusted application could
 do with the data these calls return.