[bug #18576] -execdir vs. PATH

Follow-up Comment #3, bug #18576 (project findutils): Useful idea, thanks. There's a race condition there, but there is certainly scope to reduce the number of false positives, as you say. (OK, removal of /bin/echo may not be a realistic race condition, but in other directories it may be a sli

[bug #18576] -execdir vs. PATH

Follow-up Comment #2, bug #18576 (project findutils): One additional reduction in false positives is still possible. Currently, -execdir gripes even if the PATH search would not have found the directory-relative program: $ PATH=/usr/bin find -execdir echo {} + ./a $ PATH=/usr/bin: find -execdir

[bug #18554] feat req: -exec cmd {} more args +

Follow-up Comment #15, bug #18554 (project findutils): One other thing to throw in the mix: POSIX has no requirements on -execdir. Therefore, I argue that it might make sense to have -execdir be as friendly as possible, and allow the {} to appear anywhere, rather than only immediately before th

[bug #18554] feat req: -exec cmd {} more args +

Update of bug #18554 (project findutils): Category:find => documentation Status: Invalid => None Open/Closed: Closed => Open ___

[bug #18576] -execdir vs. PATH

Follow-up Comment #1, bug #18576 (project findutils): I agree. ___ Reply to this item at: ___ Message sent via/by Savannah http://savannah.gnu.org/

[bug #18554] feat req: -exec cmd {} more args +

Follow-up Comment #13, bug #18554 (project findutils): Egmont, you raise an interesting point about the limit on the number of arguments. There is nothing in POSIX about such a limit, but I don't think there is anything that forbids it either. The -exec sh -c 'utility ... "$@" ...' sh {} + tech

[bug #18576] -execdir vs. PATH

URL: Summary: -execdir vs. PATH Project: findutils Submitted by: ericb Submitted on: Friday 12/22/2006 at 06:39 Category: find Severity: 3 - Normal Item

[bug #18554] feat req: -exec cmd {} more args +

Follow-up Comment #12, bug #18554 (project findutils): I agree that find startpoint -tests ... -exec sh -c 'scp "$@" remote:/dest' sh {} + has no security problems, because sh is not parsing the arguments. The only time you have a security problem when passing arbitrary filenames to sh is when

[bug #18554] feat req: -exec cmd {} more args +

Follow-up Comment #11, bug #18554 (project findutils): I can't see any _security_ problem with that construct, either. ___ Reply to this item at: ___ M

[bug #18554] feat req: -exec cmd {} more args +

Follow-up Comment #10, bug #18554 (project findutils): In addition to ARG_MAX (# bytes of args + environ for exec(), according to linux/limits.h) the Linux kernel has another limit: the number of command line arguments (including the 0th) cannot exceed 32767. Is this a standard, too? Is find/xarg

[bug #18554] feat req: -exec cmd {} more args +

Follow-up Comment #9, bug #18554 (project findutils): James, I believe the way I suggested using "sh -c" is perfectly safe. The security problem you are thinking of is associated with uses where the {} is part of the command, e.g. find ... -exec sh -c 'ls -l {}' \; which is not portable anyway

[bug #18554] feat req: -exec cmd {} more args +

Update of bug #18554 (project findutils): Open/Closed:Open => Closed ___ Reply to this item at: ___

[bug #18554] feat req: -exec cmd {} more args +

Update of bug #18554 (project findutils): Status:None => Invalid ___ Follow-up Comment #8: I'm marking this feature request "Invalid" on the grounds that the requested change would be

[bug #18554] feat req: -exec cmd {} more args +

Follow-up Comment #7, bug #18554 (project findutils): Thanks for the (pretty much) official interpretation Geoff. The findutils documentation would not include an example showing how to accomplish this with "sh -c" though, because of the disastrous security implications of passing untrusted data

[bug #18554] feat req: -exec cmd {} more args +

Follow-up Comment #6, bug #18554 (project findutils): POSIX definitely only allows + to be special when it immediately follows {}. I can see that because the text doesn't say "immediately follows" it could be misinterpreted, but the requirement is clear from the specified form of the primary: -

[bug #18573] xargs doesn't handle filenames with path on Windows

Update of bug #18573 (project findutils): Status:None => Invalid Assigned to:None => jay Open/Closed:Open => Closed ___