From owner-cvs-all Mon Dec 11 6:43: 4 2000 From owner-cvs-all@FreeBSD.ORG Mon Dec 11 06:43:00 2000 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 210EC37B400; Mon, 11 Dec 2000 06:43:00 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id eBBEgQe41559; Mon, 11 Dec 2000 09:42:26 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Mon, 11 Dec 2000 09:42:26 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Chris Richards Cc: Garrett Wollman , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/etc crontab In-Reply-To: <20001211013551.A30301@ethel.williams.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: robert@fledge.watson.org Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 11 Dec 2000, Chris Richards wrote: > > This is correct. However, this does not apply to the periodic binary, > > directories, or most base system files, unfortunately. Maybe we need a > > /var/run/locks with appropriate turnstile files with appropriate modes > > set. > > I don't understand what you mean to say here. What's to prevent the > creation of a /var/run/periodic.lock, for example, with mode 600? > Then periodic, running as root, will be able to aquire the advisory > lock on this file, and ordinary users won't. The possibility of a DoS > is thus eliminated. > > Am I missing something obvious? In the quoted material above, you > seem to be suggesting that it is insecure to use most base system > files as lock files. True -- but what would be the point in doing so? The point of my statement was to discourage people from using these base files, and encourage them to use files with appropriate protection modes instead. There's nothing wrong with using /var/run/periodic.lock; it would be equivilent to putting it in a seperate locks directory. The reason for my talking about what I talked about in the quoted section was that it seemed there was a specific proposal to do so. One thing we've been considering from a security perspective is breaking out the contents of /var/run into sub-directories by specific task. The reason for doing this is that, in the presence of the TrustedBSD extensions, many programs that currently run with root privileges will no longer do so, meaning they won't be able to write to /var/run to create their pid files (etc). This isn't a problem for periodic which generally runs with high levels of privilege (although perhaps it shouldn't for most of its work). Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message