Date: Tue, 24 Feb 2004 00:41:11 +0100 From: Thomas-Martin Seck <tmseck-lists@netcologne.de> To: Kris Kennaway <kris@obsecurity.org> Cc: cvs-all@freebsd.org Subject: Re: cvs commit: doc/en_US.ISO8859-1/books/porters-handbook book.sgml Message-ID: <20040223234111.GD1605@laurel.tmseck.homedns.org> In-Reply-To: <20040223223508.GB31276@xor.obsecurity.org> References: <20040223214202.GA29948@xor.obsecurity.org> <20040223222705.1873.qmail@laurel.tmseck.homedns.org> <20040223223508.GB31276@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040223234111.GD1605>