On Sat, Jul 25, 2015 at 09:02:54PM +0000, Christian Weisgerber wrote: > On 2015-07-25, Landry Breuil <[email protected]> wrote: > > > after fighting a bit with perms (_pbuild needs write access to > > ${WRKOBJDIR} so either put it in wsrc or or install -d -o _pbuild > > ${WRKOBJDIR} in the STARTUP script, _pfetch needs write to > > /usr/ports/distfiles so.. ive put it in wsrc for now) stuff finally > > started building "fine". Two things: > > - not easy to fix failures with another user. Is it possible to have > > _pbuild run umask 002 so that i can share a group with it ? I suppose > > this could be done in login.conf.. would that be a sensible default ? > > Basically you are destroying the separation between users that is > the point of _pfetch/_pbuild in the first place. > > I think the way to solve this is to dive into bsd.port.mk and have > manual builds use "${SUDO} -u _pbuild" etc. to switch to the same > user as dpb at the respective stages.
Unfortunately, this won't quite work. *most* of what happens in bsd.port.mk happens as _pbuild. Specifically, fetch happens as _pfetch. *parts* of prepare *must* happen as root. and some specific targets, such as update-patches, makesum, require the ports tree user. the prepare part is the toughest part. because you more or less need to do a kind of backflip where you output the list of deps you need, then go root and install them. The rest is just "identify target, run it as that user". I don't think it actually belongs in bsd.port.mk if you want to keep things reasonably safe. Quite simply, bsd.port.mk is not alone, it relies on modules and Makefiles, so there are ways too many places to abuse a system that starts as root. (note that dpb never runs thru any user-supplied Makefile as root). The "simplest" fix is to have dpb be able to actually run thru steps of building/working with a port manually (not ready yet) I definitively hope to have most of this ready in the near future, and it won't impact the "normal" working of dpb at all. Since you (and other people) were mistaken about the state of things. - dpb has a clean security model. Yes, it doesn't take care of all details for you. Pieces need to be completed manually. - the users were added because it's ways more convenient to work on this in-tree. Again, the default mode was not adversely affected. - the "simple" privilege separation model does work today. Start dpb as root, have it drop down to whatever user is owning the ports tree. THAT user does not read sudo/doas access. - the "complete" privilege separation model does work with some hand-holding. The provided _pbuild/_pfetch users are a correct basis for it. Ownership of various things need to be setup correctly. It can become even MORE complex in a multi-user setup, obviously. - the "complete" privilege separation model is useful for automated bulks in a chroot without any kind of user tweaking. Fixing a port that goes wrong in there is difficult (read mostly impossible). Those are the three items I'm working on: - finishing the stuff that still requires setting up for _pbuild/_pfetch users. Be aware that this won't probably EVER be completely sufficient for some build infrastructures. - having an interactive mode that allows you from drop from dpb into the right directory with the right user. Facilities needed include "preparing a port, then running it manuall". Being able to run stuff that modifies the ports tree (makesum and update-pathes/update-plist come to mind). A lot of it is "wrap around make" to run a target with the right user. The main exception being prepare, because, you know why not already use the parallel nature of dpb. - preparation of chroot. Considering how far this has gone since 5.7, I'm quite satisfied about the progress. Most of this is already useful. I have no idea how some of you thought this was 100% complete. there's been some grumpiness wrt "committing this before it was complete". Like duh, some side effects I did not foresee at all. What do you think ? that I'm unaware working on fixing ports in a completely separated model is complex ? I was definitely the first one to experience it, long before you guys. But this did not break anything that worked before. AND the "simple" privsep model is enough for saying "yes, the ports tree does not need sudo, it can be built without it."
