"chroot" breaks "socket"

We just made the discovery that doing a “chroot” prevents
further “socket” calls under QNX 6.21 PE.

We’ve been porting openntpd to QNX, and it fails at a
“socket” call, even though the parameters are valid.
The program also does a “chroot”. Before the “chroot”,
“socket” calls succced. After “chroot” to the daemons’s home
directory, “socket” calls with valid parameters return
an “address family not supported” error.

Presumably “socket” calls try to open some resource manager,
and can’t get to it because “chroot” has changed the
root of pathname space.

John Nagle
Team Overbot

It’s an old known problem (discovered it porting some code at the time when
they still called it NTO2.x rather than QNX6.x).
Your guess about the reason is correct and they know…

A workaround that I have used is to call socket() early, store away the fd
and when I actually need a new socket call openfd() instead. Yeah, it’s
messy.

“John Nagle” <nagle@downside.com> wrote in message
news:dc8dlv$cpm$1@inn.qnx.com

We just made the discovery that doing a “chroot” prevents
further “socket” calls under QNX 6.21 PE.

We’ve been porting openntpd to QNX, and it fails at a
“socket” call, even though the parameters are valid.
The program also does a “chroot”. Before the “chroot”,
“socket” calls succced. After “chroot” to the daemons’s home
directory, “socket” calls with valid parameters return
an “address family not supported” error.

Presumably “socket” calls try to open some resource manager,
and can’t get to it because “chroot” has changed the
root of pathname space.

John Nagle
Team Overbot

John Nagle wrote:

We just made the discovery that doing a “chroot” prevents
further “socket” calls under QNX 6.21 PE.

I disable chroot in my patch for openntpd :frowning:

see
http://groups.google.com/groups?hl=ru&lr=&th=a13c0c2b685aa2af&seekm=3B16ABE5.D3E12B2B%40motorola.com&frame=off

as variant start ‘io-net … -p tcpip prefix=/CHROOT_DIR …’