From owner-cvs-src@FreeBSD.ORG Mon Sep 19 10:48:43 2005 Return-Path: X-Original-To: cvs-src@freebsd.org Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C5DC16A420; Mon, 19 Sep 2005 10:48:43 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id B49F343D5E; Mon, 19 Sep 2005 10:48:36 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 3F54346BB1; Mon, 19 Sep 2005 06:48:35 -0400 (EDT) Date: Mon, 19 Sep 2005 11:48:35 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Jeremie Le Hen In-Reply-To: <20050919091447.GL51142@obiwan.tataz.chchile.org> Message-ID: <20050919114658.A95188@fledge.watson.org> References: <200509161119.j8GBJcS0080866@repoman.freebsd.org> <20050919091447.GL51142@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cvs-src@freebsd.org, src-committers@freebsd.org, Pawel Jakub Dawidek , Stefan Bethke , cvs-all@freebsd.org Subject: Re: cvs commit: src/lib/libutil pidfile.3 X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2005 10:48:43 -0000 On Mon, 19 Sep 2005, Jeremie Le Hen wrote: >>> FreeBSD src repository >>> >>> Modified files: >>> lib/libutil pidfile.3 >>> Log: >>> Pidfiles should be created with permission preventing users from >>> opening >>> them for reading. When user can open file for reading, he can also >>> flock(2) it, which can lead to confusions. >> >> This means that a monitoring tool would need to run with elevated >> privileges to determine the PID of the process to monitor, correct? > > I can't see what's the problem with disclosing daemons' PID to all > users, given they won't be able to signal it or such anyway. The problem isn't with revealing the pid, it's with allowing arbitrary access to the pidfile. Specifically, a malicious reader can open the file and acquire a lock on it, preventing the program or monitoring tools from acquiring a lock, which they try to do unconditionally as part of their activities. This is a hard-to-address issue, since sometimes you want locking to span users, and sometimes you don't. The only preventative measure, should one care enough, is to prevent untrusted parties from being able to open the file. Robert N M Watson