Igor Podlesny writes: > On Sun, 28 Apr 2019 at 00:59, <cho...@jtan.com> wrote: > [...] > > > > > > Oh, those hypocrite wankers here and there.. > > > > If you actually read the code (I know, right? Who DOES that?) you'll see > > how omalloc_ > init perfectly embarrasses you. In 6.4 it would read the symlink, then > checked the envi > ronment, and then consider the global variable malloc_options. In 6.5 it is > ... exactly > the same except that now sysctl is used instead of readlink (and hooray for > sanity). > > > > At no time was any attempt ever made by libc to force a programme to use > > only the set > tings from sysctl née malloc.conf. If you had been using the environment > variable from > the beginning you would have been in _exactly_ the same position all that > time as you a > re now. The security you think you've been relying on and have now lost was > never there > . You have been protecting yourself with security theatre. > > > > Matthew > > Matthew, LOL, what? > Read the code? > You didn't even read the whole comment thread where I did explain that > I was mostly concerned with cleared up environment other than changed > options of that variable.
No, I did. I dismissed your arguments because they come from someone who plainly has no idea what "the environment" even is. malloc.c is quite lucid. Your continuing to spout off having clearly not even glanced at it is a sorry state of affairs. But this is unix. We'll continue to hand you as much rope as you like. > Actually, I'd say that preparing chroots with malloc.conf as a symlink > is more straightforward, more enforcing and easier to verify other > than putting that as an environment option that would actually have to > be read before target is running. How in the ... Stay the hell away from my servers. > And (of course) given with symlink > it can't be so easily vanished when the whole environment is cleared > up by user space. /etc/malloc.conf can disappear exactly as easily as /etc/profile and /etc/login.conf. More easily, in fact, if a tool to "handle" broken symlinks gets involved. > All-in-all, I didn't rely on this anyways. > My question was purely theoretical and reaction was practically clumsy. :) No, the reaction was dismissive of your complete lack of research and understanding. Why should the developers or us other list members take the time to read and understand the code you can't be arsed to? In order to find out exactly how malloc handles its various configuration sources took approximately 5 minutes of browsing on cvsweb.openbsd.org to find the appropriate function and I don't even know C that well. Your unwillingness to do even that is why you're being treated with such derision. > Looks like decision made aren't subjects of discussing(?) Well, why > the hell you have those mail lists then(?) :) Building something as large as OpenBSD simply cannot be done without discussion so this is either a poor quality attempt at derision or some sort of delusion. In fact I imagine that intellient discussion is restricted to places where the general public are not permitted so that it remain intelligent - for which I am most grateful. It's quite clear why you've not been invited. tl;dr: You don't understand and your ranting is just turning you into a spectacle. Please do continue; I have popcorn. Matthew
