Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 23 Jul 2018 18:47:41 -0700
From:      Cy Schubert <Cy.Schubert@cschubert.com>
To:        Ian Lepore <ian@freebsd.org>
Cc:        Alan Somers <asomers@freebsd.org>,  src-committers <src-committers@freebsd.org>,  "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>,  "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>
Subject:   RE: svn commit: r336619 - head/lib/libc/gen
Message-ID:  <20180724014748.A948C1564@spqr.komquats.com>

next in thread | raw e-mail | index | archive | help
Well, the ssh client is still broken and IMO needs to be fixed sooner than =
later. If we want to maintain compatibility right now before any rewrite is=
 attempted, our options are limited. Just saying that if this will be broke=
n for a while we need some kind of workaround. Instead of a null pointer a =
pointer to a statically defined null string. I know it's ugly and hate to s=
uggest it but it gives us (you) more time for a better solution.

BTW, I agree about the whack-a-mole thing given the brokenness.

---
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@cschubert.com> or <cy@freebsd.org>
The need of the many outweighs the greed of the few.
---

-----Original Message-----
From: Ian Lepore
Sent: 23/07/2018 17:05
To: Cy Schubert
Cc: Alan Somers; src-committers; svn-src-all@freebsd.org; svn-src-head@free=
bsd.org
Subject: Re: svn commit: r336619 - head/lib/libc/gen

I don't wanna play whack-a-mole like that. This whole area is a great
big mess, and it needs a great big cleanup, and I've got too many other
irons in the fire right now to do that.

-- Ian

On Mon, 2018-07-23 at 16:52 -0700, Cy Schubert wrote:
> I think you misunderstood me because of my terse email. Sorry about
> that. We can address this with a NULL check in openssh's misc.c. I
> can't recall the actual path. I'll post a patch, which will explain
> it better than I can in English, as soon as I get home.
>=20
> ---
> Sent using a tiny phone keyboard.
> Apologies for any typos and autocorrect.
> Also, this old phone only supports top post. Apologies.
>=20
> Cy Schubert
> <Cy.Schubert@cschubert.com> or <cy@freebsd.org>
> The need of the many outweighs the greed of the few.
> ---
>=20
> -----Original Message-----
> From: Ian Lepore
> Sent: 23/07/2018 13:40
> To: Cy Schubert
> Cc: Alan Somers; src-committers; svn-src-all@freebsd.org; svn-src-hea
> d@freebsd.org
> Subject: Re: svn commit: r336619 - head/lib/libc/gen
>=20
> On Mon, 2018-07-23 at 13:11 -0700, Cy Schubert wrote:
> >=20
> > In message <1532364679.1344.161.camel@freebsd.org>, Ian Lepore
> > writes:
> > >=20
> > >=20
> > > On Mon, 2018-07-23 at 09:41 -0700, Cy Schubert wrote:
> > > >=20
> > > >=20
> > > > I'm sure. Rolling this libc commit back addressed the ssh
> > > > segfaults
> > > > on all my systems.
> > > >=20
> > > > ---
> > > > Sent using a tiny phone keyboard.
> > > > Apologies for any typos and autocorrect.
> > > > Also, this old phone only supports top post. Apologies.
> > > >=20
> > > > Cy Schubert
> > > > <Cy.Schubert@cschubert.com> or <cy@freebsd.org>
> > > > The need of the many outweighs the greed of the few.
> > > > ---
> > > >=20
> > > 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 !=3D NULL should fix this
> > instance.
> >=20
> >=20
> No, that doesn't work, because __pw_scan just skips setting pw_class
> and that leaves non-NULL garbage in that pointer. =A0There 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.
>=20
> I've decided that the only safe way to fix this is to have pw_scan()
> do
> the same thing getpwnam() and friends do: =A0first init the pwd struct
> to
> known values, including supplying empty strings rather than NULL
> pointers for all the char* fields, before calling __pw_scan().
>=20
> But, all of a sudden I've gotten busy with $work, so I may have to
> set
> all this aside for a few days.
>=20
> -- Ian
>=20




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180724014748.A948C1564>