On Mon, Nov 26, 2012 at 03:22:42AM +0100, Emmanuel Dreyfus wrote:
> David Laight 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 he
David Laight 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 introduced: if he
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
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),
The NetBSD core group has considered adding the
fexecve(2) or fexecve(3) syscall or function, and adding
new O_EXEC and O_SEARCH open(2) flags.
These new features may be useful, but their security properties
are not well understood. The core group is of the opinion that
these new features shou
>>> 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 e
In article <20121125152520.ga17...@panix.com>,
Thor Lancelot Simon 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 conse
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
On Thu, Nov 22, 2012 at 12:46:54PM +0100, Manuel Bouyer wrote:
> Index: uvm/uvm_vnode.c
> ===
> RCS file: /cvsroot/src/sys/uvm/uvm_vnode.c,v
> retrieving revision 1.97.8.1
> diff -u -p -u -r1.97.8.1 uvm_vnode.c
> --- uvm/uvm_vnode.c
