🚀 go-pugleaf

In article <4062:Oct1518:22:1290@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>In article <271653D6.1CE8@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
>> According to lml@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