From owner-freebsd-security Wed Sep 5 11: 2:14 2001 Delivered-To: freebsd-security@freebsd.org Received: from mailsrv.otenet.gr (mailsrv.otenet.gr [195.170.0.5]) by hub.freebsd.org (Postfix) with ESMTP id 4726837B403 for ; Wed, 5 Sep 2001 11:02:10 -0700 (PDT) Received: from hades.hell.gr (patr530-b030.otenet.gr [195.167.121.158]) by mailsrv.otenet.gr (8.11.5/8.11.5) with ESMTP id f85I20719236; Wed, 5 Sep 2001 21:02:05 +0300 (EEST) Received: (from charon@localhost) by hades.hell.gr (8.11.6/8.11.6) id f85FdLa01128; Wed, 5 Sep 2001 18:39:21 +0300 (EEST) (envelope-from charon@labs.gr) Date: Wed, 5 Sep 2001 18:39:20 +0300 From: Giorgos Keramidas To: Jochem Kossen Cc: Matt Dillon , freebsd-security@FreeBSD.ORG Subject: Re: Good practice for /tmp Message-ID: <20010905183920.A1095@hades.hell.gr> References: <200109041105.f84B5dq06623@bsd.ist-ffo.de> <20010904200054.A37836@jochem.dyndns.org> <200109041842.f84Igj693873@earth.backplane.com> <20010904234958.A487@jochem.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010904234958.A487@jochem.dyndns.org>; from j.kossen@home.nl on Tue, Sep 04, 2001 at 11:49:58PM +0200 X-PGP-Fingerprint: 3A 75 52 EB F1 58 56 0D - C5 B8 21 B6 1B 5E 4A C2 X-URL: http://students.ceid.upatras.gr/~keramida/index.html Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org From: Jochem Kossen Subject: Re: Good practice for /tmp Date: Tue, Sep 04, 2001 at 11:49:58PM +0200 > On Tue, Sep 04, 2001 at 11:42:45AM -0700, Matt Dillon wrote: > > 'man tuning' (with a recent -stable). In it I talk about /tmp vs > > /var/tmp and why it doesn't make sense to keep them separate any more. > > And these days people generally do not rm -rf /tmp at boot either. > > Maybe in future releases, the /var/tmp directory/partition or the /tmp > directory/partition could be removed? Unfortunately, according to the > FHS they both need to exist... Then, they can not be removed. Not until the FHS allows it :-) They will either be removed, or changes incompatible with the FHS be avoided at all costs. One of the beautiful things of FreeBSD is the well-known and standard places where things are. It is very nice to know what to expect and where to find it. I think that breaking this is a terrible idea. -giorgos To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message