[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 12 Oct 2021 14:38:26 -0300
From: Érico Nogueira <ericonr@...root.org>
To: <musl@...ts.openwall.com>
Subject: Re: get/set*ent functions and real world applications
On Tue Oct 12, 2021 at 12:58 PM -03, Érico 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 == NULL || stream == NULL
> || p->pw_name == 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==NULL twice, so 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.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
