On Sun, Nov 25, 2012 at 10:58:01PM -0500, Thor Lancelot Simon wrote:
Yes, I agree there is no security hazard introduced: if help from a
process outside the chroot is assumed, there are already many ways to
cirumvent chroot security.
And I strongly disagree. We've discussed this at
Does anyone know of a setup that uses a process outside of a chroot doing
descriptor passing to a chrooted process?
I wonder if we should disallow that completely (i.e. fail the anxiliary
data send if sender and recipient have different p_cwdi-cwdi_rdir)?
Martin
On Mon, Nov 26, 2012 at 10:18:42AM +0100, Martin Husemann wrote:
Does anyone know of a setup that uses a process outside of a chroot doing
descriptor passing to a chrooted process?
Yes. I mentioned some earlier in this discussion, before the thread
jumps.
I don't have time to write it up
On Mon, Nov 26, 2012 at 10:18:42AM +0100, Martin Husemann wrote:
Does anyone know of a setup that uses a process outside of a chroot doing
descriptor passing to a chrooted process?
Yes. I can point to the same example as Thor has described, but I think
that it is easy to cook up numerous
On Sat, Nov 24, 2012 at 06:53:16PM +0100, Emmanuel Dreyfus wrote:
Let's try to move forward, and I will start will a sum up of what I
understand from the standard. It would be nice if we could at least
reach consensus on standard interpretation.
I think your interpretation of the standard is
In article 20121125152520.ga17...@panix.com,
Thor Lancelot Simon t...@panix.com wrote:
On Sat, Nov 24, 2012 at 06:53:16PM +0100, Emmanuel Dreyfus wrote:
Let's try to move forward, and I will start will a sum up of what I
understand from the standard. It would be nice if we could at least
reach
O_EXEC is mutually exclusive with O_RDONLY, O_WRONLY, or O_RDWR
- simply don't include this poorly-designed functionality in NetBSD.
Unless you want to change O_RDONLY to be non-zero and version all the
syscalls that use it :-)
I don't see any need to do that, unless they were crazy enough
On Sun, Nov 25, 2012 at 07:54:59PM +, Christos Zoulas wrote:
Does everyone agrees on this interpretation? If we do, next steps are
- describe threats this introduce to chrooted processes
Given a chrooted process would need a helping process outside the
chroot (to pass it the fd), why is
On Sun, Nov 25, 2012 at 11:47:14PM +, David Laight wrote:
On Sun, Nov 25, 2012 at 07:54:59PM +, Christos Zoulas wrote:
Does everyone agrees on this interpretation? If we do, next steps are
- describe threats this introduce to chrooted processes
Given a chrooted process would
David Laight da...@l8s.co.uk wrote:
Given a chrooted process would need a helping process outside the
chroot (to pass it the fd), why is allowing the chrooted proccess to
exec something any different from it arranging to get the helper
to do it?
Yes, I agree there is no security hazard
On Mon, Nov 26, 2012 at 03:22:42AM +0100, Emmanuel Dreyfus wrote:
David Laight da...@l8s.co.uk wrote:
Given a chrooted process would need a helping process outside the
chroot (to pass it the fd), why is allowing the chrooted proccess to
exec something any different from it arranging to
11 matches
Mail list logo
