On Wed, Aug 15, 2012 at 07:44:38PM +0000, Hefty, Sean wrote: > > Somehow you need to open the verbs device before doing the choot.. I > > think once verbs is open there is no further need for sysfs and dev.. > > I could hook chroot to force this. That should fix the /sys issue. > However, the librdmacm accesses /dev when creating an event channel, > which occurs after chroot. (Maybe that call is just hopelessly > broken trying to support chroot.)
There are lots of issues with using a dev/sysfs interface instead of system calls and trying to support chroot... Not sure how rdmacm works, but verbs returns event channel FDs directly 'in-band' which avoids further use of dev.. Even better would be to use eventfd() to have user space create the event channel and pass that FD up into the kernel for this sort of stuff, but I'm not sure if eventfd() can replace all the use cases of event channels, though they are very similar. > Correct - this is one of the results of supporting fork. The ftp > daemon listens on a normal socket, then switches to an rsocket on > the first data transfer, after any fork presumably has occurred. Not sure how that switch works, but you could open the relevent ib devices on a listen? > Btw, I've tried using symlinks and running from '/'. The symlinks > don't work, but running from '/' does for rstream. Neither work for > vsftpd, likely from other security calls that it makes. Symlinks? You can bind mount sysfs and create a mini /dev/ in the chroot and things should work OK, but obviously exposing those items to the chroot significantly defeats the point of the chroot in the first place. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
