d.mon: Fix Unbounded Source Buffer in main.c file of d.mon module

[ShubhamDesai]

This Pull Request addresses the unbounded source buffer issue identified by Coverity Scan (CID: 1270265).

Changes Implemented:

• Monitor Name Length Check:

• Defined a maximum length for the monitor name (mon) as 256 characters using the MONITOR_NAME_LIMIT macro.

• Introduced checks to ensure that the mon variable, which stores the monitor name, does not exceed this defined length.

• The check if (mon && strlen(mon) < MONITOR_NAME_LIMIT) ensures that mon is not NULL and that its length does not exceed MONITOR_NAME_LIMIT.

[wenzeslaus]

While this may address the unbounded source buffer issue, it seems to me that it will just lead to another warning. The mon string goes into functions like list_cmd and somewhere there it is put to another buffer which may or may not be large enough. Maybe the issue needs to be addressed there. I checked this issue in Coverity Scan and it seems to be able to take you there.

[ShubhamDesai]

While this may address the unbounded source buffer issue, it seems to me that it will just lead to another warning. The mon string goes into functions like list_cmd and somewhere there it is put to another buffer which may or may not be large enough. Maybe the issue needs to be addressed there. I checked this issue in Coverity Scan and it seems to be able to take you there.

To address this, I have now added two checks:

Primary Check in the Main File: I implemented a length check for mon directly in the main file to ensure it is within safe limits before being passed to other functions.

Additional Checks in Individual Functions: In each of the individual functions, the length of name is also checked to provide an extra layer of safety.

For these checks, instead of using a random number, I used GPATH_MAX as the baseline. The MONITOR_NAME_LIMIT is specifically calculated as GPATH_MAX - strlen("/MONITORS/") - 1 because the "/MONITORS/" directory path is used in one of the functions to create a temporary directory. This calculation ensures that the actual monitor name length is within safe limits, considering the directory structure.

So if the checks pass in the main file still there will be additional checks inside the functions

[nilason]

I have planned to create a new G_strlcat() (local wrapper/implementation of strlcat(), to accompany G_strlcpy()), but have not got the time for that yet.
That would make this fix much less complicated. Please hold on for that (or implement for the time being with posix strlcat() if possible).

[nilason]

I have planned to create a new G_strlcat() (local wrapper/implementation of strlcat(), to accompany G_strlcpy())

Addressed by #4304.

[ShubhamDesai]

I have planned to create a new G_strlcat() (local wrapper/implementation of strlcat(), to accompany G_strlcpy())

Addressed by #4304.

Thanks. I will use it

[nilason]

G_strlcat is now in place.

[ShubhamDesai]

G_strlcat is now in place.

Done.

[nilason]

G_temp_element() + "/" + "MONITORS" + "/" is guaranteed to fit into a buffer of size GPATH_MAX, so you can (void) the return value of the three first G_strlcat (in both get_path and list_files). The name variable is coming from user, so this should be checked (and G_fatal_error if truncated).
I don't see the need for the change of main.c.

[ShubhamDesai]

G_temp_element() + "/" + "MONITORS" + "/" is guaranteed to fit into a buffer of size GPATH_MAX, so you can (void) the return value of the three first G_strlcat (in both get_path and list_files). The name variable is coming from user, so this should be checked (and G_fatal_error if truncated). I don't see the need for the change of main.c.

changes done.

No longer relevant.

[nilason]

Thanks!