svn commit: r262566 - in stable/10: crypto/openssh crypto/openssh/contrib/caldera crypto/openssh/contrib/cygwin crypto/openssh/contrib/redhat crypto/openssh/contrib/suse crypto/openssh/openbsd-comp...

[Dag-Erling Smørgrav]

Robert Watson <rwatson at FreeBSD.org> writes:
> Most userspace tools that support Capsicum will explicitly test for a
> kernel generating ENOSYS due to non-support and 'fail open' by not
> using sandboxing. That strategy becomes more complex as applications
> become more complex, and in the long term we'll want to move away from
> conditional support.  In the mean time, I'd generally recommend that
> any code being used on 9.x support runtime detection of Capsicum --
> either via feature_is_present(3) or ENOSYS back from cap_enter().  The
> ugly bit is whether or not to use other sandboxing techniques (e.g.,
> chroot()) if Capsicum can't be found, since that stuff tends to be
> pretty messy.

In this particular case, we fall back to essentially the same mechanism
as without Capsicum, i.e. setrlimit(2).  And we're talking 10 / 11, not
9...

DES
-- 
Dag-Erling Smørgrav - des at des.no