Re: ncurses 4.1 security bug

[davids () WEBMASTER COM (David Schwartz)]

> > > "Note that variables initialized by constant expressions cannot depend
> > > on the value of objects from other translation units and do not[1]
> > > require run-time initialization. Such variables are therefore safe to
> > > use in all cases."
> > >
> > > [1] The word "not" was missing until the 6th printing (see
> the errata).
> >         I believe this is a false statement and that the code I
> posted to bugtraq
> > before constitutes a counter-example. Consider the following variable
> > initialized by a constant expression:
> >
> >         MyString Foo("test");
> >
> >         'Foo' is a variable. '"test"' is a constant expression.
>
> I think this is where you part from Stroustrup (and where I may have
> misunderstood you). '"test"' is indeed a constant expression, but 'Foo'
> is not initialized from it: the constructor is called with it, so, the
> above statement does not apply to Foo. However, it does apply to
> MyString::StringCount.

        How do you think the compiler would interpret the following:

MyString Foo="test";

        It would _have_ to call a constructor. There is no other way to make a
'MyString'. So your distinction is a distinction without a difference.

        The only way to 'get' a MyString is by calling one of the MyString
constructors and any of the MyString constructors could depend upon global
objects contrstructed in other translation units.

> > Now, Stroustrup
> > claims that this "cannot depend on the value of objects from other
> > translation units." Consider the following object from another
> translation
> > unit:
> >
> >         int MyString::StringCount=0;
> >
> >         And consider the following constructor:
> >
> >         MyString(const char *)
> >         {
> >          StringCount++;
> >          ....
> >         };
> >
> >         Now, here you see that a variable initialized by a
> constant expression CAN
> > depend on the value of objects from other translation units. So
> either we
> > are both misunderstanding Stroustrup or he is incorrect.
>
> OK, you've misunderstood Stroustrup (IMO), and I've misunderstood you. I
> agree that you can't know the value of StringCount when Foo is
> initialised (because you don't know how many other MyStrings may have
> been initialised), but you can know that StringCount will have been
> zeroed before any MyStrings were initialised.

        No you cannnot know that _in_general_. The code 'int
MyString::StringCount=0;' and the code 'MyString Foo="test"' are on an equal
level -- both construct global objects and initialize them to sane states.
So in general, you can't know which will occur first.

> So now I'm left wondering
> what point you are actually trying to make (other than that we don't
> know what order global contructors are initialised in)?

        Exactly -- we can't know what order global constructors are initialized in,
so in general, we should try to avoid them. Otherwise we may wind up with
code that has subtle bugs in it. This is true whether or not our code is
suid/sgid.

        We should prefer to eliminate global objects entirely or we should use
global pointers and initialize them through 'InitInstance' or 'ClassInit'
type member functions or even just 'foo=new MyString("foo");'.

        DS