From owner-cvs-all@FreeBSD.ORG Mon Feb 23 16:00:29 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA05416A4CE for ; Mon, 23 Feb 2004 16:00:29 -0800 (PST) Received: from smtp1.netcologne.de (smtp1.netcologne.de [194.8.194.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1AB643D2F for ; Mon, 23 Feb 2004 16:00:29 -0800 (PST) (envelope-from tmseck-lists@netcologne.de) Received: from laurel.tmseck.homedns.org (xdsl-195-14-207-240.netcologne.de [195.14.207.240]) by smtp1.netcologne.de (Postfix) with SMTP id A99803897B for ; Tue, 24 Feb 2004 00:41:22 +0100 (MET) Received: (qmail 1993 invoked by uid 1001); 23 Feb 2004 23:41:33 -0000 Date: Tue, 24 Feb 2004 00:41:11 +0100 From: Thomas-Martin Seck To: Kris Kennaway Message-ID: <20040223234111.GD1605@laurel.tmseck.homedns.org> References: <20040223214202.GA29948@xor.obsecurity.org> <20040223222705.1873.qmail@laurel.tmseck.homedns.org> <20040223223508.GB31276@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040223223508.GB31276@xor.obsecurity.org> User-Agent: Mutt/1.4.2.1i Organization: private site in Germany X-PGP-KeyID: DF46EE05 X-PGP-Fingerprint: A38F AE66 6B11 6EB9 5D1A B67D 2444 2FE1 DF46 EE05 X-Attribution: tms cc: cvs-all@freebsd.org Subject: Re: cvs commit: doc/en_US.ISO8859-1/books/porters-handbook book.sgml X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2004 00:00:30 -0000 * Kris Kennaway (kris@obsecurity.org): > On Mon, Feb 23, 2004 at 10:27:05PM +0000, Thomas-Martin Seck wrote: > > > > I'm sorry, I did not obey this -- which uid/gid should I use instead? I > > do not need a fixed uid like qmail, just a starting point, pkg-install > > will try to assign squid to the first free uid starting from there. The > > same applies for the gid. It seems that I get slapped left and right > > today for www/squid :( > > Ports should always use fixed uids and gids. Suppose that squid > assigns itself one that is currently free on my machine, but is > actually listed in the porters handbook as claimed by another port. > Then later I try and install that port. The results of this will be > unpredictable, but not good. Understood. > You should choose a fixed uid and gid that is currently free, register > it in the porter's handbook and use it. Unfortunately since the 3128 > uid has already been deployed, you'll have to provide an upgrade path > for people who have a squid installation from the port with files > owned by that uid. For example, a 'make upgrade' target that chowns > the files to the new user, removes the old uid and gid and does > whatever other transition work might be needed. This would not be run > by default, but pkg-message should suggest using it if the 3128 uid > exists. OK, I'd like to register the uid 100 then. I'll implement a uid transition mechanism from 3128 to 100 and include it in the next maintainer update. > > btw: Is implementing something like WANT_UID/WANT_USER in bsd.port.mk > > something worth pursuing? There are a lot of hand-made solutions of > > varying quality in the ports system for this problem now. > > What would that do? It should create a pseudo-user with name=WANT_USER with uid=WANT_UID in a unified way to reduce the chance of a maintainer doing something silly in Makefile or pkg-install when hand-rolling this. The problem I see with this proposal is that this is hard to implement this with make(1) since ideally this should be something like 'makeuser(username, uid, gid, homedir[, loginshell if we want to make this customizable])'. An added bonus would be that the user/uid demand is clearly visible in the Makefile (if that is of any value). If implementing this in bsd.port.mk is not feasible, we should have at least a known working reference for cut-and-pasting in the porters handbook since there are at least three different implementations for the problem of creating a user/group on the fly in the ports tree.