On 2014/10/21 09:30, Theo de Raadt wrote: > What if in the future you were to get a stronger better replacement > for systrace. Would it slot into the same places in the scaffold?
I think not. IMHO dpb would be a far better place to control privs. The current scaffold calls systrace for individual build stages that have reduced privileges. A diff to remove it gets rid of calls to _SYSTRACE_CMD or to variables including _SYSTRACE_CMD in 29 places. Coverage is variable and it's a pain to have different policies for different things so we have things like "make patch" is protected but "make fetch" isn't. Now that we can build and package as non-root there are two parts needing elevated privs: pkg_add for dependencies: installs new files, modifies pkg database, execute programs (makewhatis, mkfontdir/mkfontscale, rebuild icon caches, update-desktop-databases, xml databases, and a few other less common ones). fetch: network access, write to distfiles directory These two are exactly things which dpb already has a high level of control over. >From this point until "make package" is done, privs aren't needed. Dropping separately for all the various stages from this point on doesn't make a lot of sense, just wrap the whole lot in one big privdrop instead. Then privs are needed again if you want to install the package you just built. Another problem with USE_SYSTRACE, it's under control of the ports Makefiles themselves - it gives no protection to somebody who tries to build a port they've downloaded from somewhere without reviewing it. Proper protection against this when you build a port by cd'ing to the directory and running "make" is hard. Handling privs in dpb would be safer as it can force a low-priv user to run "make" as well. One problem: dpb's UI isn't really suited to normal ports dev work. I can think of a few specific changes that would probably be enough to let it replace a direct "make" call as the main front-end without getting in the way though.
