Re: RFC: fsyscall

[Serge E. Hallyn]

On Wed, Sep 09, 2015 at 02:33:14PM -0500, Eric W. Biederman wrote:

...

> If I assume that anything file descriptor based will need another
> mechanism to filter what is allowed on a file descriptor, and as such
> will need a different mechanism (capsicum perhaps?).  That handily
> reduces the problem space, and removes almost all cases where reading
> data from userspace is interesting as I am talking about pure system calls.
> 
> The list of system calls which are not file descriptor based are listed
> below.  Most of those don't take weird parameter structures that would
> be interesting to filter.  So I think my fsyscall idea is conceptually
> reasonable.   It is not a complete solution for passing someone a well
> defined subset you are allowed to do but it is interesting.

...

> creat

Taking this as a specific example, I'm somewhat fond of the idea of
saying that we can support openat() as fd-based (let's say
capsicum-based as we know that can work), and therefore we don't need
open() or creat().  If you're designing an app so that you can fork a
task with a subset of your capabilities, then you're writing it now
anyway, so there is no reason for supporting open and creat.  Since
these are specifically very subject to TOCTTOU, saying "you must use
openat()" seems ok.

-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/