Fix coverity unbounded source buffer issues

[MarcinDigitic]

Fix coverity unbound buffer issues

During coverity scan, there are reported four issues
with unbounded source buffer for each usage of input arg
directly with syslog function.

Sample coverity test report for chsh.c file:

1. string_size_argv: argv contains strings with unknown size.
   int main (int argc, char **argv)
   [...]
2. var_assign_var: Assigning: user = argv[optind]. Both are now tainted.
   user = argv[optind];
   [...]
   CID 5771784: (Retiring certain usernames. #1 of 1): Unbounded source buffer (STRING_SIZE)
3. string_size: Passing string user of unknown size to syslog.
   SYSLOG ((LOG_INFO, "changed user '%s' shell to '%s'", user, loginsh));

Similar issue is reported three times more:
File: chfn.c, function: main, variable: user
File: passwd.c, function: main, variable: name
File: newgrp.c, function: main, variable: group

The proposed commit is a try to fix the reported issues
by adding a check for a valid user or group names.

[alejandro-colomar]

During coverity scan, there is reported an issue with unbounded source buffer for each usage of input arg directly with syslog function.

Please paste such a Coverity scan report in the commit message. It would be helpful when reviewing.

[alejandro-colomar]

Can you please rebase the branch?

---

Edit: I've done it myself for you.

v1b:

• Rebase

$ git range-diff md/master..md/topic/coverity/fix_unbound_input_buffer shadow/master..989 
1:  a90453e6 = 1:  bb741102 Fix coverity unbound buffer issues

[alejandro-colomar]

Please address the issues raised.

[alejandro-colomar]

I've converted your PR to draft, since it's not ready for review. Please address the comments.

[alejandro-colomar]

Why do we want a copy?

[MarcinDigitic]

Copy will make sure that the program can accommodate proper string length, which is passed further to syslog function. This should prevent any further issues with unbound buffers during static analyses.
Also, notice that user is allocated further in the code in other branch:
user = xstrdup (pw->pw_name);
So, with the proposed change user variable will contain allocated value in each case. And then we can safely make free before exiting.

[alejandro-colomar]

Copy will make sure that the program can accommodate proper string length, which is passed further to syslog function.

The previous call to is_valid_user_name() already makes sure that the length is good.

This should prevent any further issues with unbound buffers during static analyses.

Also, notice that user is allocated further in the code in other branch: user = xstrdup (pw->pw_name); So, with the proposed change user variable will contain allocated value in each case. And then we can safely make free before exiting.

This should be fixed in a separate commit, since it's a separate problem.

[MarcinDigitic]

This is not exactly. The static analyses tools sees that the user pointer is assigned to the program argument and as is cannot be passed to syslog. If we do only check then it does not help for the main issue: unbounded buffer passed to syslog. The xstrdup is mandatory to get rid of the static analyses tool issues. However, after adding the check, we can always mark the reported issue as false positive.
Just, it is a general good practice to make a copy of passed arguments for further usage (at least form my experience). Please, confirm that we should not do copy in this case, so I will remove any copies from the proposed PR. And I can create a separate PR with that implementation.

[alejandro-colomar]

This is not exactly. The static analyses tools sees that the user pointer is assigned to the program argument and as is cannot be passed to syslog. If we do only check then it does not help for the main issue: unbounded buffer passed to syslog. The xstrdup is mandatory to get rid of the static analyses tool issues. However, after adding the check, we can always mark the reported issue as false positive. Just, it is a general good practice to make a copy of passed arguments for further usage (at least form my experience). Please, confirm that we should not do copy in this case, so I will remove any copies from the proposed PR. And I can create a separate PR with that implementation.

I don't want to silence the warning; I want to fix the bug. And if we do merge the second patch, we will have the side-effect that the warning will vanish.

So, I confirm

[alejandro-colomar]

We don't need to free(3) in these early exit() points.

[MarcinDigitic]

Fixed

[alejandro-colomar]

Not really. I still see it there.

[MarcinDigitic]

You are correct, just the memory was already allocated, so I added free before exiting. Why we should not do free at early exit stage?

[MarcinDigitic]

If we do not do free for any allocated memory, we get issues in other code analyses tools (for example using gcc compiler with allocation checks flags).

[alejandro-colomar]

You are correct, just the memory was already allocated, so I added free before exiting. Why we should not do free at early exit stage?

Because exit(3) makes sure all memory is released. And it's just simpler (no need for having dozens of free(3) calls on the same resource).

[alejandro-colomar]

If we do not do free for any allocated memory, we get issues in other code analyses tools (for example using gcc compiler with allocation checks flags).

Please show those warnings.

[MarcinDigitic]

Some comment to exit(3):
While it is true that exit(3) ensures that all memory is freed, it is still considered good practice to explicitly free dynamically allocated memory using free() before calling exit(3) or before the program exits normally. This practice has several benefits:

• Portability: On some non-Linux systems, exit(3) might not guarantee that all resources are properly cleaned up.
  

• Code Maintainability: Explicitly freeing memory makes the code easier to understand and maintain. It shows where and why resources are being allocated and deallocated.
  

• Debugging: Explicitly freeing memory can help catch memory leaks earlier during program execution, making debugging easier.
  

Anyway, in this exact sample from the proposed changes, I can do remove free from the code. Please, confirm that this is the general practice for that repo.

[alejandro-colomar]

Some comment to exit(3): While it is true that exit(3) ensures that all memory is freed, it is still considered good practice to explicitly free dynamically allocated memory using free() before calling exit(3) or before the program exits normally. This practice has several benefits:

* ```
  Portability: On some non-Linux systems, exit(3) might not guarantee that all resources are properly cleaned up.
  ```

free(3) is guaranteed by ISO C to free all allocated memory, IIRC.

* ```
  Code Maintainability: Explicitly freeing memory makes the code easier to understand and maintain. It shows where and why resources are being allocated and deallocated.
  ```

Having 13 different points where we free(name); in the same function is exactly the opposite of code maintainability.

[alejandro-colomar]

Why do we want a copy?

[MarcinDigitic]

Copy will make sure that the program can accommodate proper string length, which is passed further to syslog function. This should prevent any further issues with unbound buffers during static analyses.
Also, notice that user is allocated further in the code in other branch:
user = xstrdup (pw->pw_name);
So, with the proposed change user variable will contain allocated value in each case. And then we can safely make free before exiting.

[alejandro-colomar]

Copy will make sure that the program can accommodate proper string length, which is passed further to syslog function.

I don't think this is true. The check right above already makes sure the length is good.

This should prevent any further issues with unbound buffers during static analyses. Also, notice that user is allocated further in the code in other branch: user = xstrdup (pw->pw_name); So, with the proposed change user variable will contain allocated value in each case. And then we can safely make free before exiting.

This makes sense, but please fix it in a separate PR after we merge the first one.