From owner-freebsd-questions  Mon Aug 11 13:42:22 1997
Return-Path: <owner-freebsd-questions>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id NAA28714
          for questions-outgoing; Mon, 11 Aug 1997 13:42:22 -0700 (PDT)
Received: from david.siemens.de (david.siemens.de [139.23.36.11])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA28622
          for <freebsd-questions@freebsd.org>; Mon, 11 Aug 1997 13:39:43 -0700 (PDT)
Received: from salomon.mchp.siemens.de (salomon.siemens.de [139.23.33.13])
	by david.siemens.de (8.8.6/8.8.5) with ESMTP id WAA20315
	for <freebsd-questions@freebsd.org>; Mon, 11 Aug 1997 22:38:22 +0200 (MDT)
Received: from curry.mchp.siemens.de (daemon@curry.mchp.siemens.de [146.180.31.23])
	by salomon.mchp.siemens.de (8.8.6/8.8.5) with ESMTP id WAA03929
	for <freebsd-questions@freebsd.org>; Mon, 11 Aug 1997 22:38:22 +0200 (MDT)
Received: (from daemon@localhost)
	by curry.mchp.siemens.de (8.8.7/8.8.7) id WAA13919
	for <freebsd-questions@freebsd.org>; Mon, 11 Aug 1997 22:38:21 +0200 (MET DST)
From: Andre Albsmeier <Andre.Albsmeier@mchp.siemens.de>
Message-Id: <199708112038.WAA19822@curry.mchp.siemens.de>
Subject: Please explain why this is a security hole in /etc/daily
To: freebsd-questions@freebsd.org
Date: Mon, 11 Aug 1997 22:38:09 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL31 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-questions@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Hi,

using 2.2-STABLE we find the following in /etc/daily:

# This is a security hole, never use 'find' on a public directory
# with -exec rm -f as root.  This can be exploited to delete any file
# on the system.
#
#find / \( ! -fstype local -o -fstype rdonly \) -a -prune -o \
#       \( -name '[#,]*' -o -name '.#*' -o -name a.out -o -name '*.core' \
#          -o -name '*.CKP' -o -name '.emacs_[0-9]*' \) \
#               -a -atime +3 -exec rm -f -- {} \;
#
#
# The same security hole.  Purge the temp directories from unused stuff.
# Note that we must not accidentally clean the X11 lock files.
#
# Use at your own risk, but for a long-living system, this might come
# more useful than the boot-time cleaning of /tmp.  If /var/tmp and
# /tmp are symlinked together, only one of the below will actually
# run.


Please tell me, why this is so, and how I could clean /tmp securely
since this is no longer done at startup. I have experimented a bit
with find and symlinks but didn't find anything unsecure :-)

Thanks very much,

	-Andre