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

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

Reply via email to