>>>>> "gabriel" == gabriel rosenkoetter <gr@eclipsed.net> writes:
    gabriel> On Tue, Jul 17, 2001 at 03:28:14PM -0400, Michael Richardson wrote:
    >> chroot(2) should not.
    >> (I do not even think that the fchdir() checks should be done. I've used
    >> used the fact that you can fchdir() out of the chroot in some applications)
    >> 
    >> But, I think that we should offer a facility like jail(2), etc. that does
    >> what is being asked for. 

    gabriel> Except that extant software relies on things like fchdir() out of
    gabriel> a chroot() to be disallowed by the operating system. BIND, for
    gabriel> instance. Do you really want to check and patch all the software
    gabriel> that uses the present state of NetBSD's chroot() to use a brand,
    gabriel> new jail() instead?

  No.
  I do not propose that.
  
  I would suggest:
    1) introduce jail(2)
    2) introduce chroot43(2), original behaviour.

  Note that this chroot() in the presence of fchdir() only matters if you have
fd's that reference directories that are still open.  Since the part before
chroot(2) has to be carefully audited anyway, it doesn't change things too
much.

    gabriel> Also, chroot() is understood in other operating systems (Solaris
    gabriel> comes to mind) to have the meaning we now give it, not the meaning
    gabriel> you'd like it to have. It is also, imho, the more logical

  I do not know if POSIX has a view.

  I know that BSD 4.3 (BSDi 1.x and BSDi 2.0), and Solaris 1, as well as
stock AT&T SVR4.2 had the original behaviour. It was useful in some esoteric
situations. Of course, those systems did not have fchdir(2) as I recall.

  Again, I just want to have jail(2) or some such, and I think that many
applications would be overjoyed with that. 

  The other thing that I wanted to be able to do was exec a fd. That way,
I could have one process create a jail, open another executable, give up
root, chroot, etc. and then exec the new program, without having to have
even the binary of the program in the chroot area.

  And, given the ability to pass FDs in Unix domain sockets, that would
permit some kind of client/server executable authorization system possible.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [