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
On Mon, Nov 26, 2012 at 01:49:09AM +0300, Alan Barrett wrote:
If necessary, the open(2) syscall could be versioned so that
O_RDONLY is no longer defined as zero.
Actually we could redefine (say)
O_RDONLY0x1
O_WRONLY0x2
O_RDWR (O_RDONLY
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 09:01:10AM +, David Laight wrote:
O_SEARCH0x4
O_EXEC 0x8
The standard notes that O_EXEC and O_SEARCH are never used together
and therefore may be set to the same binary value.
--
Emmanuel Dreyfus
m...@netbsd.org
Can anyone make sense out of the following sequence of events (on 4.0, I have
to admit)?
1. A lengthy ahd(4) Dump Card State
2. sd0(ahd0:0:0:0): Check Condition on CDB 0x2a ...
SENSE KEY: Aborted Command
ASC/ASCQ: ASC 0x4d ASCQ 0x19
(ASC 4D is TAGGED OVERLAPPED COMMANDS)
3. ahd0:
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
