On Sun, Apr 28, 2019 at 02:07:44AM +0700, Igor Podlesny wrote:

> 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 environment, 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 settings 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 are 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.
> 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. And (of course) given with symlink
> it can't be so easily vanished when the whole environment is cleared
> up by user space.
> All-in-all, I didn't rely on this anyways.
> My question was purely theoretical and reaction was practically clumsy. :)
> Looks like decision made aren't subjects of discussing(?) Well, why
> the hell you have those mail lists then(?) :)
> For users to come and thank you and say you did all the best possible
> way only? :)
> To never question any decision? Seriously? No, really? C'mon, you
> gotta be kidding.
> -- 
> End of message. Next message?

The mechanism is in the docs as well, not only in the code. You
ignored my post about the symlink being confusing and error prone
since the time it is read (before or after the chroot) is program
dependent. It might even depend on options gives to a program when the
first malloc call happens, making it even more unclear which symlink
is being used.  Add the complexity with respect to unveil and pledge
and it is clear why we replaced it. 


Reply via email to