From owner-freebsd-security  Fri Nov  1 07:37:08 1996
Return-Path: owner-security
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id HAA14316
          for security-outgoing; Fri, 1 Nov 1996 07:37:08 -0800 (PST)
Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA14309
          for <freebsd-security@FreeBSD.org>; Fri, 1 Nov 1996 07:37:05 -0800 (PST)
Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.7.5/8.7.3) with UUCP id IAA15573; Fri, 1 Nov 1996 08:35:48 -0700 (MST)
Received: from localhost (marcs@localhost) by alive.ampr.ab.ca (8.7.5/8.7.3) with SMTP id IAA20709; Fri, 1 Nov 1996 08:35:22 -0700 (MST)
Date: Fri, 1 Nov 1996 08:35:21 -0700 (MST)
From: Marc Slemko <marcs@znep.com>
X-Sender: marcs@alive.ampr.ab.ca
To: Mikael Karpberg <karpen@ocean.campus.luth.se>
cc: freebsd-security@FreeBSD.org
Subject: Re: /etc/security
In-Reply-To: <199611011141.MAA08439@ocean.campus.luth.se>
Message-ID: <Pine.BSF.3.95.961101083130.20595B-100000@alive.ampr.ab.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-security@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

On Fri, 1 Nov 1996, Mikael Karpberg wrote:

> According to Marc Slemko:
> > > >From the man page:
> > >      -0      Changes xargs to expect NUL (``\0'') characters as seperators,
> > >              instead of spaces and newlines.  This is expected to be used in
> > >              concert with the -print0 function in find.
> > > 
> > > This avoids execing a costly interpreter and keeps the scripts using xargs,
> > > which is useful with very long path lists.
> > 
> > Except for the minor problem that xargs does not have a -0 option
> > on FreeBSD.  GNU xargs does and OpenBSD xargs does.  Below is the
> > diff from OpenBSD to implement the change.  I think it is a worthwhile
> > change, although I haven't really looked too much at the OpenBSD
> > way of doing it to see if it is a good implementation.
> [...patch deleted...]
> 
> Is there anything speaking against this being added?
> And the change in /etc/security taking place?
> I for one would really like to see the scan handle all legal filenames.
> Speaking of which... Is the /tmp cleaning job also errnous in that it will
> not handle all names? Any other scripts in etc which have the same error?

The /tmp cleaning job in /etc/daily should work fine but it is, as it
says, a security risk.

It should be modified to use the new (in -current) -delete option to find
which avoids the race condition.