Re: seccomp for 2.6.11-rc1-bk8

[daw@taverner.cs.berkeley.edu (David Wagner)]

Andrea Arcangeli  wrote:
>On Sun, Jan 23, 2005 at 07:34:24AM +0000, David Wagner wrote:
>> [...Ostia...]  The jailed process inherit an open file
>> descriptor to its jailor, and is only allowed to call read(), write(),
>> sendmsg(), and recvmsg().  [...]
>
>Why to call sendmsg/recvmsg when you can call read/write anyway?

Because sendmsg() and recvmsg() allow passing of file descriptors,
and read() and write() do not.  For some uses of this kind of jail,
the ability to pass file descriptors to/from your master is a big deal.
It enables significant new uses of seccomp.  Right now, the only way a
master can get a fd to the jail is to inherit that fd across fork(),
but this isn't as flexible and it restricts the ability to pass fds
interactively.

Andrea, I understand that you don't have any use for sendmsg()/recvmsg()
in your Cpushare application.  I'm thinking about this from the point of
view of other potential users of seccomp.  I believe there are several
other applications which might benefit from seccomp, if only it were
to allow fd-passing.  If we're going to deploy this in the mainstream
kernel, maybe it makes sense to enable other uses as well.  And that's
why I suggested allowing sendmsg() and recvmsg().

It might be worth considering.

[Sorry for the very late reply; I've been occupied with other things
since your last reply.]