[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241107214159.XFJ1n5cL@steffen%sdaoden.eu>
Date: Thu, 07 Nov 2024 22:41:59 +0100
From: Steffen Nurpmeso <steffen@...oden.eu>
To: oss-security@...ts.openwall.com
Subject: Re: shell wildcard expansion (un)safety
Steffen Nurpmeso wrote in
<20241107210420.v7ZcHYHZ@...ffen%sdaoden.eu>:
|Solar Designer wrote in
| <20241107041658.GA10363@...nwall.com>:
||On Thu, Nov 07, 2024 at 01:08:19AM +0100, Steffen Nurpmeso wrote:
||> David A. Wheeler wrote in
||> <F60236E0-F65A-4441-9E62-64EE55016B2C@...eeler.com>:
||>|> On Nov 5, 2024, at 11:12 PM, Solar Designer <solar@...nwall.com> \
||>|> wrote:
||>|
||>|> ... over the years we gained things like ...
||>|>
||>|> find . -mindepth 1 -maxdepth 1 -type f -print0 | xargs -0 grep text --
||>|
||>|The "-print0" and "-0" options have been widely implemented, but
||>|POSIX 2024 finally formally adds them. So I urge using them where they
||>|make sense, as they counter embedded linefeed characters in filenames.
||>
||> 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?
POSIX.1-2024 says, for xargs, on page 3600, lines 123174 ff.:
If the -0 option is specified, the application shall ensure that
arguments in the standard input are delimited by null bytes.
If multiple adjacent null bytes occur in the input, each null
byte shall be treated as a delimiter.
If the standard input is not empty and does not end with a null
byte, xargs should ignore the trailing non-null bytes (as this
can signal incomplete data) but may use them as the last
argument passed to utility.
So it standardizes behaviour as it exists in real life
applications.
(This is pretty unfortunate.)
...
|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
...
|So then the above paragraph even reflects code reality.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
|
|And in Fall, feel "The Dropbear Bard"s ball(s).
|
|The banded bear
|without a care,
|Banged on himself fore'er and e'er
|
|Farewell, dear collar bear
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
