Hello everyone,

Earlier today I got pointed to proposal N3940, which attempts to
extend the C++ standard library with filesystem access routines. While
reading through the proposal and its list of issues (N4096), I thought
I should get in touch to express my concerns.

Over the last couple of years there has been a lot of development in
the area of capability-based security. The University of Cambridge
Computer Laboratory has developed a system called Capsicum [1] that is
part of FreeBSD and in the process of being merged into Linux. My
company, Nuxi, is working on a cross-platform computing environment
called CloudABI that can be used to develop secure, sandboxed
UNIX-like applications [2].

The intent behind Capsicum and CloudABI is that applications can only
access resources by using a capability -- a token. There is no global
namespace. The filesystem can only be accessed through handles that
only expose (parts of) the filesystem namespace. More concretely, it
means that the following construct is not permitted when using
Capsicum:

int fd = open("/etc/passwd", O_RDONLY);

The following construct, however, is allowed, assuming some_directory
is a file descriptor to an open directory:

int fd = openat(some_directory, "my/file.txt", O_RDONLY);

The idea is that this method allows you to programmatically determine
which actions an application is allowed to perform. For example, a
simple web server may only possess a file descriptor to its web root
directory during execution, meaning its access is restricted to just
the files it should serve through the web.

This is good from a security point-of-view. It allows software
developers to reduce the impact of a security vulnerability without
requiring a complex static set of rules to be provided up front (say,
like AppArmor). Another advantage is that software becomes easier to
test. Different parts of the filesystem are used if a program is
invoked with a different set of file descriptors. System testing of
applications may become trivial.

The reason why I'm getting in touch is that the interfaces described
in N3940 seems to have complete disregard for separate filesystem
namespaces. It assumes that the system only provides a single global
filesystem namespace. It looks like an almost direct mapping to POSIX
prior to the 2008 edition. If applications are built on top of this
interface, they will be hard to adapt to systems that use Capsicum.

I would strongly suggest that all of the global functions are placed
in a separate 'class filesystem'. By default there would only be a
single instance that attempts to access the global filesystem
namespace. If an implementation supports the POSIX 2008 interface, it
may provide extensions to construct filesystem instances based on file
descriptors to directories.

This would also address the issues raised in comment #54 in N4096,
raised by Google (who also happened to fund the development of
Capsicum). It could permit filesystem access that is less prone to
race-conditions, but also make it possible to construct artificial
filesystems as part of unit tests.

I hope that concerns in this area can be addressed before
standardization, as right now this proposal would negatively affect
projects like Capsicum and CloudABI. If needed, I am willing to help
out.

Relevant links:

[1] Capsicum: http://www.cl.cam.ac.uk/research/security/capsicum/
[2] Nuxi CloudABI: https://github.com/NuxiNL/cloudlibc

Best regards,
--
Ed Schouten <ed@nuxi.nl>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.