|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
Subject: Re: standard libraries (STL, GLib,...)
From: Solar Designer (solar
false.com)Date: Mon Aug 28 2000 - 02:32:30 CDT
- Next message: Daniel Jacobowitz: "Re: Traceroute problems"
- Previous message: Stephen Satchell: "Re: Traceroute problems"
- In reply to: David A. Wagner: "Re: standard libraries (STL, GLib,...)"
- Reply: Solar Designer: "Re: standard libraries (STL, GLib,...)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> >
> > Perhaps it would be nice if setenv() refused to set a variable with
> > '=' in its name, what do you think?
>
> I mostly agree, except that one can imagine some far-fetched scenario
> where a program relies on setenv() to overwrite the previous name-value
> binding, which can be unfortunate.
>
> What do you think of something like the following? Is it any better?
> (And, is it too ugly or too Posix-uncompliant?)
>
> int setenv(char *name, char *value, int replace) {
> char *p = strchr(name, '=');
> if (p) {
> if (/* something; I don't know what */) {
> syslog(LOG_USER | LOG_WARNING,
> "Possible attack attempt: setenv(`%s',`%s',%d)", name, value, replace);
The syslog() should definitely NOT be used.
> }
> if (replace) {
> /* Clear any existing bindings, just in case caller wanted us to */
> unsetenv(name);
> *p = '\0';
> unsetenv(name);
> }
I can imagine a _broken_ application where this change would make
things worse, -- env vars may be used to restrict things, as well
(such as, LD_PRELOAD'ing a library to work around a libc bug).
Signed,
Solar Designer
- Next message: Daniel Jacobowitz: "Re: Traceroute problems"
- Previous message: Stephen Satchell: "Re: Traceroute problems"
- In reply to: David A. Wagner: "Re: standard libraries (STL, GLib,...)"
- Reply: Solar Designer: "Re: standard libraries (STL, GLib,...)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]