src/{chfn,chsh,passwd}.c: Allow bad names (regression fix)

[alejandro-colomar]

    These programs don't add new users.  Because they handle existing users,
    they should handle them with whatever names they already have, including
    bad names.
    
    A recent commit that added some username syntax validation blindly
    removed support for bad names in these programs.  Fix that regression.

Also, pass the badname flag as a function parameter instead of an extern variable. This makes it easier to analyze which programs allow badnames and which don't.

Also, remove an inconsistent (and seemingly accidental) allowance of badnames in group names in newusers(8).

Fixes: 326889c (2024-10-22; "Fix coverity unbound buffer issues")
Fixes: a2cd3e9 (2019-10-04; "chkname.c, pwck.c, useradd.c, usermod.c, newusers.c: Allow names that do not conform to standards")
Cc: @MarcinDigitic , @edneville

[ikerexxe]

The changes look great, but I think we can make a couple of quick changes to improve the review. If you could squash commits 1 and 4, it would really help tidy up the commit history and make the final diff much easier to read.
Also, to keep our pattern consistent and avoid introducing a new global variable, I'd highly suggest expanding the existing option_flags struct to include the badnames boolean instead. That way, we can just pass it down wherever it's needed and keep our state centralized.

[alejandro-colomar]

The changes look great, but I think we can make a couple of quick changes to improve the review.

If you could squash commits 1 and 4, it would really help tidy up the commit history and make the final diff much easier to read.

One problem with that is that it would squash a breaking change with a refactor. I prefer having it separate, so that the diff for the breaking change is minimal.

Also, to keep our pattern consistent and avoid introducing a new global variable, I'd highly suggest expanding the existing option_flags struct to include the badnames boolean instead. That way, we can just pass it down wherever it's needed and keep our state centralized.

I'd like to refactor that separately. I also want to unify the struct option_flags and put it in a header file. I prefer doing that in a separate PR, though.

[ikerexxe]

One problem with that is that it would squash a breaking change with a refactor. I prefer having it separate, so that the diff for the breaking change is minimal.

I see your point here. This was just a preference, so let's keep it as it is

I'd like to refactor that separately. I also want to unify the struct option_flags and put it in a header file. I prefer doing that in a separate PR, though.

I’m really looking forward to seeing this change. At first, I considered doing it this way, but I felt that there were utilities that wouldn’t use all the options, so I ruled it out. I also considered using getters and setters for the values, but that’s very OOP

[ikerexxe]

LGTM! So, let's merge it