Xref: utzoo comp.unix.shell:584 comp.lang.perl:2577 alt.security:1673
Path: utzoo!attcan!uunet!aplcen!samsung!sdd.hp.com!wuarchive!julius.cs.uiuc.edu!psuvax1!rutgers!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.unix.shell,comp.lang.perl,alt.security
Subject: Re: Beware xargs security holes
Message-ID: <4062:Oct1518:22:1290@kramden.acf.nyu.edu>
Date: 15 Oct 90 18:22:12 GMT
References: <63404@iuvax.cs.indiana.edu> <1990Oct9.172621.13484@cbnews.att.com> <271653D6.1CE8@tct.uucp>
Organization: IR
Lines: 19

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