http://blog.gmane.org/gmane.comp.gnu.findutils.bugs hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5427 <pre> The are many formats the -printf option supports. What's wrong with looking it up in the man page? Have a nice day, Berny </pre> Bernhard Voelker 2013-05-16T07:59:18 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5426 <pre>* lib/buildcmd.c (bc_push_arg): Take prefix length into account to avoid state-&gt;argbuf overflow. * NEWS: Mention this fix. --- It would be a security issue if one could control factors triggering this bug, which include a directory with thousands of files. ChangeLog | 7 +++++++ NEWS | 2 ++ lib/buildcmd.c | 2 +- 3 files changed, 10 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog index e6914ff..7b4f3e0 100644 --- a/ChangeLog +++ b/ChangeLog &lt; at &gt;&lt; at &gt; -1,3 +1,10 &lt; at &gt;&lt; at &gt; +2013-05-15 Dmitry V. Levin &lt;ldv&lt; at &gt;altlinux.org&gt; + +find: fix potential buffer overflow in -execdir and -okdir. +* lib/buildcmd.c (bc_push_arg): Take prefix length into account +to avoid state-&gt;argbuf overflow. +* NEWS: Mention this fix. + 2013-04-22 Paul Eggert &lt;eggert&lt; at &gt;cs.ucla.edu&gt; More removal of support for -perm +MODE. diff --git a/NEWS b/NEWS index 4349a21..010ba6e 100644 --- a/NEWS +++ b/NEWS &lt; at &gt;&lt; at &gt; -30,6 +30,8 &lt; at &gt;&lt; at &gt; The documentation for xargs now warns about parallel processes (xargs Some bugs in 4.5.11 were fixed without adding them to the bug database, though they are in the ChangeLog: +*** find -execdir/-okdir potential buffer overflow. + *** Use of [[ ... ]] in find/testsuite/sv-bug-32043.sh *** Don't delete header files in "lib/" for "make clean". diff --git a/lib/buildcmd.c b/lib/buildcmd.c index d135692..2616ed6 100644 --- a/lib/buildcmd.c +++ b/lib/buildcmd.c &lt; at &gt;&lt; at &gt; -364,7 +364,7 &lt; at &gt;&lt; at &gt; bc_push_arg (struct buildcmd_control *ctl, if (!terminate) { - if (state-&gt;cmd_argv_chars + len &gt; ctl-&gt;arg_max) + if (state-&gt;cmd_argv_chars + len + pfxlen &gt; ctl-&gt;arg_max) { if (initial_args || state-&gt;cmd_argc == ctl-&gt;initial_argc) error (EXIT_FAILURE, 0, </pre> Dmitry V. Levin 2013-05-15T23:48:21 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5425 <pre>Hi, I find that things like '%H' of -printf is very hard to remember. Is there an easy way to remember '%*'? </pre> Peng Yu 2013-05-15T16:09:26 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5424 <pre>URL: &lt;http://savannah.gnu.org/bugs/?38963&gt; Summary: depend on unlinkat gnulib module Project: findutils Submitted by: gagern Submitted on: Sa 11 Mai 2013 10:12:32 CEST Category: find Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Originator Name: Originator Email: Open/Closed: Open Discussion Lock: Any Release: None Fixed Release: None _______________________________________________________ Details: As discussed in https://bugs.gentoo.org/show_bug.cgi?id=469206, building findutils-4.5.11 on OS X will fail due to lack of an unlinkat function. The find/pred.c file requires that function unconditionally. Previous releases apparently shipped that file due to some gnulib-internal dependencies which seem to have changed since then. The clean solution would be explicitely importing that module so you can rely on that function. https://www.gnu.org/software/gnulib/MODULES.html#module=unlinkat _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?38963&gt; _______________________________________________ Nachricht gesendet von/durch Savannah http://savannah.gnu.org/ </pre> Martin von Gagern 2013-05-11T08:12:33 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5423 <pre>Follow-up Comment #1, bug #38899 (project findutils): I'am talking about the GnuWin Version of find. Probably sourceforge rather than here is the proper place to report the bug. _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?38899&gt; _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ </pre> anonymous 2013-05-06T06:45:42 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5422 <pre>URL: &lt;http://savannah.gnu.org/bugs/?38899&gt; Summary: Find by Last Access Time Actually Modifies the Last Access Time by Itself Project: findutils Submitted by: None Submitted on: Sun 05 May 2013 06:48:07 PM UTC Category: find Severity: 3 - Normal Item Group: Wrong result Status: None Privacy: Public Assigned to: None Originator Name: alec lee Originator Email: alecleekya&lt; at &gt;hotmail.com Open/Closed: Open Discussion Lock: Any Release: 4.2.20 Fixed Release: None _______________________________________________________ Details: find "C:/bin" ( -amin -15 ) -print tested with version 4.2.20 Test done in windows XP where last access time update was enabled (attention NTFS last access time will only be updated if the last access time is &gt; around 1hr ago). So advance the clock by 1 hr for every test. The above command actually modifies the last access time by itself to the current time so all the files under c:/bin are always returned regardless of the files last access time. _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?38899&gt; _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ </pre> anonymous 2013-05-05T18:48:09 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5421 <pre>Follow-up Comment #12, bug #38474 (project findutils): Sure, but POSIX says that find should treat the existing file mode as 0 here. For example, POSIX says that "find /tmp -perm +rw" finds all files under /tmp that are read-write to everyone and that have no other permissions. Admittedly "+rw" means the same thing as "=rw" here, and "=rw" is clearer; but the point is that there's good precedent for saying that 'find -perm' should mimic chmod's syntax, even when the syntax is obscure. _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?38474&gt; _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ </pre> Paul Eggert 2013-04-24T08:03:30 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5420 <pre>Update of bug #38474 (project findutils): Status: Fixed =&gt; None _______________________________________________________ Follow-up Comment #11: I've applied Paul's updated patch. However, I think I agree with Eric on the interpretation of the mode argument. I propose not to reinstante -perm +MODE with different semantics in the future. The fact that this went wrong in the first place underlines the fact that more regression test cases are needed for -perm. I don't find the argument from compatibility with chmod very convincing since the mode argument to chmod is understood to describe a modification to the mode of an existing file. In the case of -perm, there is no existing file mode. Hence a description of how the mode should be interpreted that makes perfect sense for chmod could still be confusing for find -perm. This puts me in the uncomfortable position of wondering if mode_change is really the best basis for find -perm; I'm not sure this is really the intended use case for that function. But my first point above probably applies to gnulib too; if I wanted mode_compile to reject mode strings of the form +MODE I should probably have contributed a gnulib test case which enforced that. Anyway I'm marking this bug as not-fixed because better tests are needed (in findutils, at least). _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?38474&gt; _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ </pre> James Youngman 2013-04-24T07:13:13 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5419 <pre>Follow-up Comment #10, bug #38474 (project findutils): Thanks for catching that problem with 'havekind'. A patch is attached. I don't think the code should reject -perm /+0111, or -+0111 for that matter. 'chmod +0111 foo' has a well-defined meaning with GNU chmod, and it's nicer if 'find' is compatible with 'chmod'. At some point in the future I would like to remove the special check that prohibits 'find -perm +0111', and allow it to work as well, compatibly with GNU chmod. Now's not a good time to do that, as people may be expecting the no-longer-supported syntax, but after another few years we should be able to enable 'find -perm +0111' with the new meaning. Checking explicitly for octal digits helps make the code a bit clearer to me, but it's no big deal. (On architectures where numbers from 0 through 7 can be represented as immediate bits, it might be a tiny bit faster to check for octal digits than to check for decimal digits, but again it's no big deal...) (file #27931) _______________________________________________________ Additional Item Attachment: File name: havekind.txt Size:2 KB _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?38474&gt; _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ </pre> Paul Eggert 2013-04-22T22:24:42 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5418 <pre>Follow-up Comment #9, bug #38474 (project findutils): Paul's patch, as modified in commit 9040c5d, is not quite right. The bool havekind variable is now useless; it is set to true by all branches of the switch statement. It can safely be deleted, along with a later switch statement when havekind is still false. The code doesn't reject -perm /+0111. These lines: if (NULL == change || (perm_expr[0] == '+' &amp;&amp; '0' &lt;= perm_expr[1] &amp;&amp; perm_expr[1] &lt; '8')) should probably instead be: if (NULL == change || (perm_expr[mode_start] == '+' &amp;&amp; c_isdigit(perm_expr[mode_start + 1])) (Note that although c_isdigit will allow '8' and '9', those bogus digits will have already caused the 'NULL == change' branch to be true; so it is a reasonable simplification). _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?38474&gt; _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ </pre> Eric Blake 2013-04-22T22:03:08 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5417 <pre>Update of bug #38474 (project findutils): Status: None =&gt; Fixed _______________________________________________________ Follow-up Comment #8: I applied the patch in a slightly modified form, mainly to acommodate some changes I'd already made to find.texi. I also modified the patch to update the manpage as well. Updated patch is both attached and pushed. (file #27930) _______________________________________________________ Additional Item Attachment: File name: 0001-Remove-support-for-obsolete-perm-MODE-syntax.patch Size:10 KB _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?38474&gt; _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ </pre> James Youngman 2013-04-22T21:26:31 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5416 <pre>Update of bug #38791 (project findutils): Status: None =&gt; Fixed Assigned to: None =&gt; jay _______________________________________________________ Follow-up Comment #1: Thanks for the patch. I've applied it. _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?38791&gt; _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ </pre> James Youngman 2013-04-22T20:32:55 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5415 <pre>Actually I just forgot it. Fixed now. Thanks. </pre> James Youngman 2013-04-22T20:19:36 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5414 <pre> Thanks. As far as I can see they do exactly what I wanted. I assume you had good reasons to not enable assertions, i.e., keep the '#define NDEBUG'. Regards Peter </pre> Peter Breitenlohner 2013-04-22T06:59:31 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5413 <pre> I've just done that in the current git tree. Thanks for the suggestion, James. </pre> James Youngman 2013-04-21T22:10:29 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5412 <pre>Added, thanks. </pre> James Youngman 2013-04-21T17:50:24 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5411 <pre>On Mon, Feb 13, 2012 at 6:35 AM, Titkov, Sergey &lt;Sergey.Titkov&lt; at &gt;billing.ru&gt; wrote: I'm not sure. Can you reproduce the same problem with a plan text file (containing the dir /B ouput) as input to xargs? What's the exit code of xargs in this case? Are you using Cygwin? If yes, try asking for help on the Cygwin mailing list. Thanks, James. </pre> James Youngman 2013-04-21T17:41:46 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5410 <pre>Sorry, I had applied your patch of the previous day, but missed this one. It's now applied. </pre> James Youngman 2013-04-21T17:37:29 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5409 <pre>Follow-up Comment #7, bug #38474 (project findutils): Let's follow Eric's mild preference and make it an error. I'm attaching a proposed patch. (file #27916) _______________________________________________________ Additional Item Attachment: File name: patch.txt Size:7 KB _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?38474&gt; _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ </pre> Paul Eggert 2013-04-21T07:38:18 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5408 <pre>URL: &lt;http://savannah.gnu.org/bugs/?38791&gt; Summary: doc: fix typos uncovered by texinfo 5.0 Project: findutils Submitted by: eggert Submitted on: Sat 20 Apr 2013 10:10:29 PM PDT Category: find Severity: 3 - Normal Item Group: Compilation Failure Status: None Privacy: Public Assigned to: None Originator Name: Paul Eggert Originator Email: Open/Closed: Open Discussion Lock: Any Release: None Fixed Release: None _______________________________________________________ Details: 'make' fails for findutils if texinfo 5.0 is installed. I'm attaching the obvious patch. _______________________________________________________ File Attachments: ------------------------------------------------------- Date: Sat 20 Apr 2013 10:10:29 PM PDT Name: patch.txt Size: 1kB By: eggert obvious patch &lt;http://savannah.gnu.org/bugs/download.php?file_id=27915&gt; _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?38791&gt; _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ </pre> Paul Eggert 2013-04-21T05:10:30 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5407 <pre> Well to the letter of the law it would break POSIX "compliance". Though this is in the context of "ERRORS", whereas SIGPIPE could be thought of normal process flow, and is handled as such elsewhere. I'd be inclined to only apply the letter of the law if the POSIXLY_CORRECT env variable was set. Also it might be something to bring up with POSIX. thanks, Pádraig. </pre> Pádraig Brady 2013-04-20T17:13:59 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.gnu.findutils.bugs