The following issue has been SUBMITTED.
======================================================================
https://austingroupbugs.net/view.php?id=1872
======================================================================
Reported By: steffen
Assigned To:
======================================================================
Project: 1003.1(2024)/Issue8
Issue ID: 1872
Category: Shell and Utilities
Type: Clarification Requested
Severity: Editorial
Priority: normal
Status: New
Name: steffen
Organization:
User Reference:
Section: find
Page Number: 2946
Line Number: 98444 ff.
Interp Status: ---
Final Accepted Text:
======================================================================
Date Submitted: 2024-11-07 21:34 UTC
Last Modified: 2024-11-07 21:34 UTC
======================================================================
Summary: find: clarify "less safe" statement
Description:
On the oss-security list there is a thread "shell wildcard expansion
(un)safety".
A snippet of a thread i am involved in:
<code>
|> To add that the POSIX core developers mention (APPLICATION USAGE):
|>
|> It should be noted that using find with -print0 to pipe input to
|> xargs -r0 is less safe than using find with -exec because if
|> find -print0 is terminated after it has written a partial
|> pathname, the partial pathname may be processed as if it was
|> a complete pathname.
|
|Shouldn't that behavior be treated as an xargs implementation bug or at
|least shortcoming, and fixed as such? I hope POSIX doesn't require it?
Now, i am not a POSIX core developer. POSIX.1-2024 was developed
for over a decade (even almost one and a half) with many hundreds
of issues fixed through discussions in regular meetings.
A first thought is that the now really included (four decades too
late!) sh(1)ell's "pipefail" option was agreed upon long after the
text above appeared for the -print0/-r0 addition. If that is true
the above text is anyway a correct statement less the partial
pathname because the undesired "termination" will not be reflected
in the exit status of the pipe.
|In other words, if the input stream to "xargs -0" doesn't end in a NUL,
|xargs must not process the last maybe-partial string. I've just checked
Other than that i would agree.
|GNU findutils xargs (not the latest version, though) and it does have
|this problem - something we'd want to fix?
>From a glance "git show master:findutils/xargs.c::process0_stdin()"
of busybox also does
int c = getchar();
if (c == EOF) {
if (p == s)
goto ret;
c = '\0';
}
*p++ = c;
if (c == '\0') { /* NUL or EOF detected */
...
So then the above paragraph even reflects code reality.
</code>
Desired Action:
"Do something about it" :-)
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
2024-11-07 21:34 steffen New Issue
2024-11-07 21:34 steffen Name => steffen
2024-11-07 21:34 steffen Section => find
2024-11-07 21:34 steffen Page Number => 2946
2024-11-07 21:34 steffen Line Number => 98444 ff.
======================================================================
