[PATCH] setenv|putenv rc checking (lib)
slynko at tronet.ru
Thu Sep 29 10:20:14 PDT 2005
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:
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?
More information about the Submit