svn commit: r336619 - head/lib/libc/gen

[Ian Lepore]

On Mon, 2018-07-23 at 13:11 -0700, Cy Schubert wrote:
> In message <1532364679.1344.161.camel at freebsd.org>, Ian Lepore
> writes:
> > 
> > On Mon, 2018-07-23 at 09:41 -0700, Cy Schubert wrote:
> > > 
> > > I'm sure. Rolling this libc commit back addressed the ssh
> > > segfaults
> > > on all my systems.
> > > 
> > > ---
> > > Sent using a tiny phone keyboard.
> > > Apologies for any typos and autocorrect.
> > > Also, this old phone only supports top post. Apologies.
> > > 
> > > Cy Schubert
> > > <Cy.Schubert at cschubert.com> or <cy at freebsd.org>
> > > The need of the many outweighs the greed of the few.
> > > ---
> > > 
> > My current working theory is that some of the software that uses
> > __pw_scan() pre-stages a pointer-to-empty-string into the pw_class
> > field and my change ruined that by replacing it with a NULL
> > pointer.
> > Other callers of __pw_scan() don't do that, they just assume
> > they're
> > running as root and will get all the fields populated.
> Yes. A simple check for pw->pw_class != NULL should fix this
> instance.
> 
> 

No, that doesn't work, because __pw_scan just skips setting pw_class
and that leaves non-NULL garbage in that pointer.  There is a pw_fields
field that uses bits to indicate which fields were parsed, but almost
nothing uses it, so I'm reluctant to rely on it because this same kind
of unexpected crash of some random tool will happen if there's anything
that fills out a pwd struct without making those flags valid then calls
pw_copy() which would rely on them being valid.

I've decided that the only safe way to fix this is to have pw_scan() do
the same thing getpwnam() and friends do:  first init the pwd struct to
known values, including supplying empty strings rather than NULL
pointers for all the char* fields, before calling __pw_scan().

But, all of a sudden I've gotten busy with $work, so I may have to set
all this aside for a few days.

-- Ian