From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,
	RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4
Received: (qmail 28415 invoked from network); 12 Oct 2021 17:40:31 -0000
Received: from mother.openwall.net (195.42.179.200)
  by inbox.vuxu.org with ESMTPUTF8; 12 Oct 2021 17:40:31 -0000
Received: (qmail 5204 invoked by uid 550); 12 Oct 2021 17:40:29 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 5171 invoked from network); 12 Oct 2021 17:40:28 -0000
X-Virus-Scanned: Debian amavisd-new at disroot.org
Mime-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail;
	t=1634060414; bh=oDM0gZlZpucSui8IIzjXm2ORkMwFdpkmV2tMNKJ23wE=;
	h=Subject:From:To:Date:In-Reply-To;
	b=EKIbK3Rm70yxnQoF6aa1IehAhHaLsonLz49B7yGRrtwVjl4SL8fk14ytCcectaJja
	 Tlj3lEdtHq0ZKaX0A8qA7JWqHvmBlvM5+IddFi6wUiLS+FGPgDvep4f+NNd5w2z+0k
	 cXiaXK6sfpSexFNMDwKLEfQCMRNvM9t3n7A8Ibm/m+mRaGDpWll0o8mGiZCGbGry4f
	 hQxQGMfukdxM7qidq1K8AEzAqosI8nTlsub6BhhJbdU7t9cyJtYMTIx+RlLpueNUYj
	 7dYYkRCcpg8V3pEIHm1AxS5qpAKyihg0CFyFfImyeHBw6eWfIZsFoqogn1WFhlSNRq
	 hNK1EjlYJiCjg==
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
From: =?utf-8?q?=C3=89rico_Nogueira?= <ericonr@disroot.org>
To: <musl@lists.openwall.com>
Date: Tue, 12 Oct 2021 14:38:26 -0300
Message-Id: <CEXM19L2KGHT.1T7RL15VID4Z7@mussels>
In-Reply-To: <CEXJWX5RRUMD.13LHQA50E3RQ3@mussels>
Subject: Re: [musl] get/set*ent functions and real world applications

On Tue Oct 12, 2021 at 12:58 PM -03, =C3=89rico Nogueira wrote:
> On Mon Oct 11, 2021 at 9:38 PM -03, (GalaxyMaster) wrote:
> > On a Glibc system, the putpwent() call with pw->pw_name being NULL will
> > fail to
> > produce a record. If the pw->pw_name field is not NULL, then it will
> > produce a
> > record with the name followed by empty string fields, like
> > "user::0:0:::",
> > which is more expected in my opinion.
>
> Sorry, I wasn't clear. I was talking about glibc's implementation:
>
> if (p =3D=3D NULL || stream =3D=3D NULL
> || p->pw_name =3D=3D NULL || !__nss_valid_field (p->pw_name)
> || !__nss_valid_field (p->pw_passwd)
> || !__nss_valid_field (p->pw_dir)
> || !__nss_valid_field (p->pw_shell))
> {
> __set_errno (EINVAL);
> return -1;
> }
>
> It requires that all of pw_name, pw_passwd, pw_dir and pw_shell be non
> null and only contain valid characters (that's what __nss_valid_field
> checks for, and it seems they are checking for pw_name=3D=3DNULL twice, s=
o I
> will see about sending a patch their way).
>
> So, requiring some specific fields is compatible with glibc's impl, and
> then for the other fields we should take care to print an empty string
> instead of "(null)". I think that's a pretty valid change to implement.

Ugh, my mistake. __nss_valid_field is only checking for invalid
characters, those strings can be null. The only required string is
indeed pw_name.