I've worked hard to allow for dpb to work in a new model, most specifically so that chroot always works, and also to have a slightly better security model.
The corresponding code and documentation have been committed, but they probably need people to play with it a bit more to make sure all kinks are gone. There are some important implications with respect to ports bulk building security. In the new model, dpb no longer requires any kind of sudo operation, it's moved to a privilege separation model. - dpb should be started as root, it will drop privileges as needed. - the basic core of dpb runs as root, but any time it's actually looking at the ports tree, it will drop to a build_user (which has to be specified). This user does not require any root access. - dpb will stay root to run the STARTUP script, and also to run pkg_add/pkg_delete to handle dependencies. - fetch can be run as a separate user (thus, the build_user shouldn't even have internet access under normal rules). Commands in the ports tree will actually be run as chroot -u build_user /somedir cmd Thus, all builds are chrooted "by default" with / being used as a root when there's no chroot. Distant buils will ssh from root to root, and run the same command (chroot -u build_user /somedir cmd) on the distant host. This is somewhat necessary so that killing dpb will correctly propagate signals to all running jobs, which has been an issue with previous attempts at running chroot. That new user model is probably going to become the ONLY operating model of dpb in the near future. Having options suck and is a problem for maintenance and security. People running bulks should transition as soon as they can. The manpage mentions which files belong to whom. It is highly advisable to have a specific build user without sudo rights and (possibly) restricted net access.
