[cap-talk] Directory Fd's and designation

[Mark Seaborn]

"Rob Meijer" <capibara at xs4all.nl> wrote:

> To make a bit clearer what the goal of all this would be, a litle example
> of its potential use:
> 
> * Process A runs with all the permissions/authority of user a, or all
>   permissions defined by the a program AppArmor profile.
> * Process A creates /home/a/work/input, and writes some files into it.
> * Process A creates /home/a/work/output
> * Process A opens a Fd for both directories, sets apropriate mask bits so
>   the first designates read only access, and the second designates that
>   new files can be created , but no new directories.
> * Process A defines that its next child should run starved from any access
>   permissions.
> * Process A starts up process B handing it the two directory Fd's.
> * Process B can use the at* system calls with the directory Fd's,
>   it can now read all files in the input dir, and write result files
>   into the output dir, but does not have access to any other permission
>   that process A or user/program a did.

The question is, what programs will do this?  No existing programs use
directory FDs this way, so I assume we are talking about new code.  If
we are talking about new code, why does this need to be done in the
kernel?  You could do most of this in user space using something like
the Plash object-capability protocol for accessing directories
(eg. opening files and receiving FDs as a result), layered on top of
existing Unix domain sockets.

The ways in which you might want to limit access directories are
almost limitless and it would be more extensible to implement that by
proxying in user space rather than trying to pick a set of permission
bits for directory FDs to be implemented by the kernel.

For example, Plash provides several directory proxy objects that
implement Plash's FsObj interface
(http://plash.beasts.org/wiki/FsObj), including:
 * FsObjReadOnly: a proxy object that allows only read access to the
   object being wrapped
 * FsObjCopyOnWrite: layered/copy-on-write directories
 * FsObjUnion: union directories
 * FsObjFab: in-memory-only directories and symlinks
 * FsObjMountTable: proxy object for implementing namespaces

Of these, only FsObjReadOnly could be implemented using the kind of
permission bits on directories that you are proposing.
FsObjMountTable is quite important for implementing a file powerbox
interface for legacy programs, i.e. for binding files/directories into
a file namespace dynamically.

The only point on your list that can't straightforwardly be
implemented in user space is the fifth one -- "Process A defines that
its next child should run starved from any access permissions."  BTW,
it would be cleaner if a process could drop permissions after fork()
and before execve() than if it requested that permissions be dropped
on the next fork().

I really think to get the benefit of the object-capability model you
need to have proxyable objects, otherwise there is no extensibility.
You need proxyability in order to make it easy to build abstractions
for access control.

Regards,
Mark