Beware xargs security holes

[The Grey Wolf]

In article <4062:Oct1518:22:1290 at kramden.acf.nyu.edu> brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
>In article <271653D6.1CE8 at tct.uucp> chip at tct.uucp (Chip Salzenberg) writes:
>> According to lml at cbnews.att.com (L. Mark Larsen):
>> >I never much cared for xargs since it limits you to an argument list of
>> >only 470 bytes.
>> For the most common use of xargs -- "find ... | xargs command" -- the
>> script below, called "many", does a good job.  Since it doesn't spawn
>> a subshell, it isn't prone to metacharacter-caused security problems.
>
>But it's still susceptible to filenames with carriage returns, and will
>be until find has a -print0 option. Please, please, please don't claim
>that your xargs is by any means secure when a standard command like
>
>  find / -name '#*' -atime +7 -print | xargs rm
>
>lets a malicious user remove every file on the system. Maybe it's
>unreasonable of me to want others to live up to my standard of security,
>but in my eyes no \n-parsing xargs qualifies as ``a good job.'' Sorry.
>
>---Dan

Having looked at the output of find and the input of xargs, there
is definitely a hole ("NO SHIT, SHERLOCK!") (yeah, I saw the other posts).
Just the same, xargs kind of loses functionality if you take away its
ability to handle newlines.  "find $fs -conditions ... -print | xargs cmd"
certainly has more advantages to it than the hole can really offset.
If you're worried about the above command running as root, then don't.
Or don't use "xargs" in that case, use "-exec rm {} \;".
It's that simple.  Don't cripple an otherwise very useful command.
-- 
"This is *not* going to work!"
				"Well, why didn't you say so before?"
"I *did* say so before!"
...!{ucbvax,acad,uunet,amdahl,pyramid}!unisoft!greywolf