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 FreeBSD.org> [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