From owner-freebsd-hackers Tue Mar 21 08:21:08 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA24275 for hackers-outgoing; Tue, 21 Mar 1995 08:21:08 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id IAA24269 for ; Tue, 21 Mar 1995 08:21:05 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA06745; Tue, 21 Mar 95 09:14:45 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9503211614.AA06745@cs.weber.edu> Subject: Re: Denial of resource attacks To: jbeukema@hk.super.net (John Beukema) Date: Tue, 21 Mar 95 9:14:44 MST Cc: hackers@FreeBSD.org In-Reply-To: from "John Beukema" at Mar 21, 95 12:05:02 pm X-Mailer: ELM [version 2.4dev PL52] Sender: hackers-owner@FreeBSD.org Precedence: bulk > Well, surprise, rm -r fails when the maximum path length is exceeded. I > was forced to write another shell script to step down the chain to the end > and then remove the directories one by one. Time down 1 1/2 hours (am not > very good at shell programing). This should be unlikely, since the directory is relatively pathed. The recursive descent chdirs. > 3. Might it be a good idea to limit the creation of sub-directories > when the max path length will be exceeded, so that rm -r will > continue to work? This is ineffective. The limit is on the basis of the copyin of path names using copyinstr -- the limit being PATH_MAX (1024). A relatively pathed create will not exceed the path length, even if the total agregate path length from / would. Unless you are suggesting the path resoloution ought to determine the path length up to the path component being created... In which case, happy FS hacking as you do the necessary disallowing of all sym links and hard links on dirs (even for root). The current file system doesn't store the parent directory of an inode; lookup would be prohibitively expensive, and symbolic link translation on lookup is going to throw a wrench into things big-time (it's unavoidable). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.