From owner-freebsd-security Sun Mar 14 11:16:18 1999 Delivered-To: freebsd-security@freebsd.org Received: from woodstock (lakertya-1-70.mdm.mkt.execpc.com [169.207.118.70]) by hub.freebsd.org (Postfix) with ESMTP id E4E5915038 for ; Sun, 14 Mar 1999 11:16:13 -0800 (PST) (envelope-from hamilton@pobox.com) Received: from pobox.com (localhost [127.0.0.1]) by woodstock (Postfix) with ESMTP id 53FE63E; Sun, 14 Mar 1999 13:15:42 -0600 (CST) To: Peter Jeremy Cc: robert+freebsd@cyrus.watson.org, freebsd-security@FreeBSD.ORG Subject: Re: ACL's In-reply-to: Your message of "Sun, 14 Mar 1999 20:07:28 +1000." <99Mar14.195521est.40346@border.alcanet.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 Mar 1999 13:15:42 -0600 From: Jon Hamilton Message-Id: <19990314191542.53FE63E@woodstock> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <99Mar14.195521est.40346@border.alcanet.com.au>, Peter Jeremy wrote: } Robert Watson wrote: } >BTW, I'd really like to get rid of hard links -- they allow users to } >retain copies of setuid files after the owner thinks they are deleted. } } This strikes me as overkill. Why not just change either rm(1) or } unlink(2) to remove set[gu]id bits on executables? This would have } the same net effect and the behaviour can probably be justified. It would have to be an option and not the default behavior, otherwise you'd have a real mess when you really did want to delete just one link to a file and leave the rest alone. -- Jon Hamilton hamilton@pobox.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message