Re: [PATCH] setenv|putenv rc checking (lib)

[Alexey Slynko <slynko@xxxxxxxxx>]

Matthew Dillon пишет:
>     Ok, I have a few comments.
>
>     First, if a setenv(..., 1) fails, that should be a terminal error.
>     malloc should not fail for such a small allocation, period.  Many
>     programs will not operate as expected if their setenv() calls fail!
>
>     Second, the real problem here is that these functions are badly 
>     designed (which isn't our fault).  Frankly, functions which
>     internally malloc() small amounts of data should *NEVER* be allowed
>     to fail.  That is, the failure of such malloc's should be terminal.
>
>     Most programs do not bother checking for error codes in such cases,
>     and for good reason... because they don't expect the procedures to
>     ever fail unless something is really screwed up.  The only real
>     issue, in fact, has to do with SUID/SGID programs where ignoring
>     such failures can lead to a root compromise (which has occured in the
>     past)... not because the fail naturally, but because someone 
>     intentionally causes them to fail by reducing the datasize resource
>     limit to a ridiculously small value.
>
>     So the question is, do we hack all the code to pieces to check for
>     failure cases which will never happen under normal operation, for these
>     small-allocations, or do we try to cover the issue with a system-wide
>     sysctl which defaults to causing libc to err() out.  e.g. something like:
>
>     sysctl user.small_alloc_failure_is_fatal=1
>
>     And then whenever libc hits one of these situations it would check
>     the sysctl and do the err() automatically.  I would far prefer that,
>     in fact, then hacking up all our utility code.
Yes, it was my first idea.But I agree with joerg, that the behaviuor of 
setenv in user context and library context should be different. How we 
can differ it with sysctl?