As I already spoke with Theo this needs to be carefully looked app by app and not remove chroot just because, it needs to make sense first and foremost.
This diff was also not one by random choice, spamd(8) was one of the first programs I actually studied, pledge(2)d it and use daily and sent it as a showcase for other programs where we could apply the same logic, but then again if it actually makes sense without getting into a personal vendetta of changing every single program that calls chroot(2). Regarding downstream I'm "not too worried" since if you follow us either you are already using OpenBSD or you should apply best policies already, one being porting both pledge/unveil but we all know it will takes years until someone goes ahead and do that, so that being said I'm worried on the other side if we do this and make the programs vulnerable to fs access where they shouldn't have. All things considered looking only at our own garden my diff makes sense so I'm asking for OKs specially from deraadt@ On 11:22 Wed 31 Jul , Theo de Raadt wrote: > Ingo Schwarze <schwa...@usta.de> wrote: > > > /* > > * When porting this program to a platform lacking pledge(2), > > * don't forget to at least properly chroot(2) the child instead. > > */ > > I'm going to translate that to another plausible comment to put > throughout the source tree. > > /* When porting this program to a platform lacking strlcpy(3) > * don't forget to avoid buffer overflows with whatever replacement > * functions you use. > */ > > But I really don't see the benefit of such lines of text. > > Outsiders won't read the text, and it wastes our screen real estate. > > > The spamd(8) utility does look like a plausible candidate for porting, > > but i'm not sure how familiar the porters are with OpenBSD ways, > > so the removal of chroot(2) might easily cause misunderstandings. > > Well good, I hope they get burned. > > People who don't have sufficiently advanced technology need to grow up, > and add such things. This isn't 1980 anymore. >
