[cap-talk] New version of ViewFs/Capfs (MinorFs)
Rob Meijer
capibara at xs4all.nl
Wed May 21 16:18:13 CDT 2008
I've just put up a new version of MinorFs.
The main issue addressed in this version is the ability to use interpreted
code (perl,java? e?) as pseudo persistent processes by creating a config
file for the interpreter that defines the identifying parts (commandline,
enviroment etc) of the interpreted code as pseudo persistent process.
For clarity a short description of the two filesystems:
--------------------------------------------------------------
ViewFs attempts to provide processes with two symbolic links to PRIVATE
directory trees, the first symbolic link is the 'home' link, that should
provide the process, as a new or first incaranation of a pseudo persistent
process, persistent private data that is by default only available to
that persistent process. The private directory tree pointed to is initially
created by ViewFs, but is further maintained by CapFs.
The second link is the 'tmp' link that provides access to a simular private
directory tree. The difference between the tmp and the home link is that the
directory pointed to by the tmp link will get recursively deleted by viewfs
after the non persistent process has disapeared.
One of the main functionalities that ViewFs implements is the
functionality of distinguishing the pseudo persistent processes from
eachother. It does this using the folowing scheme.
First it tries to create a binary-unique digest using the folowing
information:
* The AppArmor confinement information from /proc/$pid/attr/current
* The paths from /proc/$pid/maps that are marked as being executable pages.
* For each executable /proc/$pid/maps entry it checks in the /etc/apparmor
dir for config file entries specifying aditional info.
* If a config file specifies so, /proc/$pid/cmdline is also used.
* If the config file names them, named /proc/$pid/environ entries are
also used.
The use of the config files should allow interpreted code (perl,java etc) to
make use of ViewFs.
Next to the executable digest above, the uid is also used.
For unique executables running under a specific uid, pseudo persistent
processes make use of so called slots to distinguish between multiple
processes running simultaniously. By default an executable uid combination
will get 16 slots.
The config file can specify less or more slots for an executable.
----------------------------------------------------------------------
The CapFs filesystem is a simple pseudo filesystem that provides for
decomposable directory tree structure. Each node in CapFs has two (or
more) paths under what it is available.
* <strongParentPath>/<weakPath>
* <strongPath>
The strong paths contain sparse tokens that turn the paths into something
equivalent to so called password capabilities. A directory tree can thus
be effectively decomposed and independently delegated. CapFs does not use
any regular access control, knowledge of a strong path is sufficient to
authorize unattenuated access to a subtree.
Knowledge of a strong path does however convey neither knowledge nor
authority to parent nodes. We can thus recognize that delegatable
decomposition is the functionality that CapFs provides.
It is important to note that each trunk of the CapFs tree starts of with a
ViewFs created node that is bound by ViewFs to a pseudo persistent process
identity.
CapFs subtrees can be accessed and used in the same way normal directory
trees can with a few exceptions:
* chmod is silently discarded, all authority is by knowledge of the strong
path.
* link is not available.
* symlink is only allowed if the target is a valid strongpath or
strongpatent/weakpath
in CapFs or AttenuateFs. (NOTE: v0.2.0 not yet implemented)
In order to get a delegatable path for a node, the extended attributes are
used.
You can use the 'attr' command from the commandline or scripts, or from
within a program the listxattr and getxattr calls can be used.
------------------------------------------------------------------------
I'd be especially interested in feedback from people using interpreted
code with repect to the usability of ViewFs/CapFs from their favorite
interpreted language code.
T.I.A.
Rob J Meijer
More information about the cap-talk
mailing list