The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix
It was also leading to segfaults; pw can be NULL when control reaches these
lines now, because of the way my previous change restructured the loops.
Reported by: lwhsu@
pw_scan(3) has been fixed in a way that doesn't perturb other callers of
it or the getpwnam(3) family.
Make pw(8) showuser work the same with or without -R <path> for non-root
users. Without -R, pw(8) uses getpwnam(3), which will open master.passwd
for the root user or passwd for non-root users. With -R <path> pw(8) was
always opening <path>/master.passwd, which would fail for a non-root user,
then falsely claim the userid you're trying to show doesn't exist.
Now for a non-root user it opens <path>/passwd, and populates the fields in
the returned struct passwd which aren't present in that file with well-known
canonical values, which duplicates the behavior of getpwnam(3). The net
effect is that the showuser output is identical whether using -R or not.
users. Without -R, pw(8) uses getpwnam(3), which will open master.passwd
for the root user or passwd for non-root users. With -R <path> pw(8) was
always opening <path>/master.passwd, which would fail for a non-root user,
then falsely claim the userid you're trying to show doesn't exist.
Now for a non-root user it opens <path>/passwd and zeroes out the 3 fields
that aren't available in the passwd file, which duplicates the behavior of
getpwnam(3). The net effect is that the showuser output is identical
whether using -R or not.
Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
No functional change intended.
Just like with freelocale(3), I haven't been able to find any piece of
code that actually makes use of this function's return value, both in
base and in ports. The reason for this is that FreeBSD seems to be the
only operating system to have such a prototype. This is why I'm deciding
to not use symbol versioning for this.
It does seem that the pw(8) utility depends on the function's typing and
already had a switch in place to toggle between the FreeBSD and POSIX
variant of this function. Clean this up by always expecting the POSIX
variant.
There is also a single port that has a couple of local declarations of
setgrent(3) that need to be patched up. This is in the process of being
fixed.
PR: 211394 (exp-run)
