On 4/27/19 8:23 AM, Otto Moerbeek wrote: > Additionally, in many cases using a symlink has unclear effects, since > it is hard to determine if the first malloc call (malloc inits itself > on first use) happens before of after the chroot call. I would argue > that in many cases people were thinking they had per-chroot settings, > while actually they had not.
Also, as Otto informed me on twitter, base is quite happy with the stronger settings. The code that really needs weaker settings inside the chroot, probably needs the stronger settings the most, technically (if it didn't break). I like the more convenient sysctl. Be careful though, S cost me a couple of hours last night. After much success on many systems without issue. I foolishly enabled S at the same time as PHP5 with suhosin to php7 upgrade, All the statically built pledged parts, femail, PHP output and reop, worked individually but femail would not send the mail when directly sent from PHP. I still don't understand how malloc S could cause that but turning back to the default, solved the breakage. In any case, the inherent clarity of what is happening under the hood in golang (php sh flags etc.) and the loss of php suhosin function whitelist feature (again) that has avoided so many CVEs has affirmed moving to golang. Therefore, I am not so bothered about finding why unless it helps OpenBSD somehow, which I doubt?
