> > I'm not against adding IPv6 functionality to jail(2), my point is
> > merely that until somebody who has sufficient time & ability to 
> > fiddle with it does it, it's not going to happen.
> > 
> > The usual rule applies:
> > 
> > "Great idea, why don't you send me patches which does this ?"
> 
> OK, then I'll try making patches and send you.
> My current Idea is that adding a new member, a pointer to
> sockaddr to the jail structure, and leave current ip_number
> member for backward compatibility.
> (Also with associated changes in kernel and the jail command)

> There's been a discussion a few weeks ago on freebsd-security on
> this very matter. See attached mail below.
> 
> The conclusion was that jail(2) should be fixed to use a sockaddr
> instead of a 32 bit int to specify the address.
> 
> That seems to be the first logical step, even before making jail(2)
> IPv6-compliant.

In implementing jail sockaddr extension trial, I found some
problems, and now have an possible solution.

problems:
  -Any process in a jail might want to use several protocol
   families at the same time.
   So jail(2) need to specify every adress of those possible
   address families.
   (AF_INET, AF_INET6, AF_IPX, AF_APPLETALK, and so on)
   To do this, jail structure need to have not only a sockaddr
   but several sockaddrs list, and they are specified via
   jail(2).

   But I don't like such a extension, because,
    -It is complicated. Error checking will be diffcult.
    -User interface will also become complicated, and
     difficult to use.

  -As already commented, checking those addresses which
   already specified by other jail'ed processes is necessary.


solution:
  Don't specify addresses via jail(2), and let kernel select
  any non binded address.
  Loop in_ifaddr list and try in_pcblookup_hash() for each
  of addresses, just as in_pcbbind does it to search for non
  binded port.


A weak point of this solution is that processes in a same jail
won't be necessariliy binded to a same address, but does it
matters?

Yoshinobu Inoue



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Reply via email to