Repository navigation
Backport 2407 - #2438
Backport 2407#2438
Conversation
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| } else { | ||
| char *path_with_prefix = oscap_path_join(prefix, pbuf); | ||
| fd = open(path_with_prefix, O_RDONLY); | ||
| fd = open(path_with_prefix, O_RDONLY | O_NONBLOCK); |
| } else { | ||
| char *path_with_prefix = oscap_path_join(prefix, pbuf); | ||
| fd = open(path_with_prefix, O_RDONLY); | ||
| fd = open(path_with_prefix, O_RDONLY | O_NONBLOCK); |
| NULL); | ||
| probe_item_add_msg(itm, OVAL_MESSAGE_LEVEL_ERROR, | ||
| "File \"%s\" status can't be read: errno=%d, %s.", | ||
| pbuf, errno, strerror(errno)); |
There was a problem hiding this comment.
The errno is only reliable right after the fstat fails. The probe_item_create and probe_item_add_msg can modify the errno value, which can cause that the strerror(errno) will produce a wrong/misleading message. The original PR calls oscap_strerror_r right after the fstat fails to prevent the message being broken by later errno changes. We need a similar solution here. The function oscap_strerror_r is available in maint-1.3 so I think it can be used as in the original PR.
| "hash_type",OVAL_DATATYPE_STRING, h, | ||
| NULL); | ||
| probe_item_add_msg(itm, OVAL_MESSAGE_LEVEL_ERROR, | ||
| "File \"%s\" status can't be read0:, %s.", |
There was a problem hiding this comment.
Remove the stray zero
| "File \"%s\" status can't be read0:, %s.", | |
| "File \"%s\" status can't be read:, %s.", |
| ); | ||
| probe_item_add_msg(itm, OVAL_MESSAGE_LEVEL_ERROR, | ||
| "File \"%s\" status can't be read: errno=%d, %s.", | ||
| pbuf, errno, strerror(errno)); |
There was a problem hiding this comment.
This file also suffers from the problem with errno that I mentioned yesterday.
The filehash and filehash58 probes call `open(pbuf, O_RDONLY)` without checking the file type. If the target is a FIFO (named pipe), `open()` blocks indefinitely waiting for a writer. The user simply runs `mkfifo ~/somefile` — when the compliance scan traverses their home directory, the entire oscap process hangs. Additionally, a symlink to `/dev/zero` causes an infinite read loop in `crapi_mdigest_fd()`. Both problems will be avoided by checking whether the file isn't blocking and is a regular file. The function `crapi_mdigest_fd` isn't modified by the commit but the issue is avoided because the function is guarded by the checks. This is a adjusted backport of OpenSCAP#2407 Co-Authored-By: Jan Černý <jcerny@redhat.com> Co-Authored-By: opencode <noreply@opencode.ai>
|
jan-cerny
left a comment
jan-cerny
left a comment
There was a problem hiding this comment.
I have confirmed that the PR correctly backports the linked PR to the target branch.
3 participants
This isn't a straight backport some adjustments had to be made to due to merge conflicts.
Backport #2407