cvs commit: src/usr.sbin/sysinstall main.c

David Schultz das at FreeBSD.ORG
Mon Apr 30 23:18:49 UTC 2007

On Mon, Apr 30, 2007, Andrey Chernov wrote:
> On Mon, Apr 30, 2007 at 11:00:43AM -0700, Alfred Perlstein wrote:
> > * Andrey A. Chernov <ache at> [070430 08:17] wrote:
> > > ache        2007-04-30 15:16:19 UTC
> > > 
> > >   FreeBSD src repository
> > > 
> > >   Modified files:
> > >     usr.sbin/sysinstall  main.c 
> > >   Log:
> > >   Preparing for upcoming POSIXed putenv() rewrite:
> > >   don't allow const as putenv() arg, dup it
> > >   
> > >   Revision  Changes    Path
> > >   1.75      +1 -1      src/usr.sbin/sysinstall/main.c
> > 
> > Maybe this was mentioned on the lists, but couldn't there be some
> > kind of define that old code could use like #define BSD_PUTENV?
> Why? We must follow standards to stay in line with possible concurrents, 
> and we already are several years later with that. Even in case some 
> applications will be found incompatible, they forced to follow standards 
> too to continue works in the modern environment.
> > I'm concerned that all these changes could lead to security
> > holes.
> Please be specific. Which changes exactly you means? Changes to 
> applications works with any putenv() kind, they are just portablility 
> fixes, no holes there. Changes to the library aren't under the question 
> too: you can just directly modify **environ variable from your own code 
> bypassing any setenv and putenv - they are just convenient interface.

I think Alfred is absolutely right, and this is a pretty major
POLA violation. As a result of these changes, I've got two ports
(so far) and some model checking software that won't build/run
anymore. If we've been doing something right for years, changing
it around in order to inherit SVR4 bugs seems like a bad
plan. Holding up your POSIX banner doesn't really make things
okay; POSIX wasn't written by God, and we choose to ignore various
parts of it. And considering the way various setuid programs
attempt to sanitize their environment before doing a fork/exec,
the change may very well have security implications.

That said, I have important deadlines and no time to deal with
this now, so I'm just reverting to yesterday's sources until I do.

More information about the cvs-src mailing list