From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Darrington Subject: Re: User accounts Date: Tue, 13 May 2014 14:49:32 +0200 Message-ID: <20140513124931.GA11836@jocasta.intra> References: <87d2fidrnm.fsf@gnu.org> <20140513081752.GA10442@jocasta.intra> <87d2fhkhcd.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:44159) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WkC9R-0008NV-Cz for guix-devel@gnu.org; Tue, 13 May 2014 08:49:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WkC9N-0004n7-60 for guix-devel@gnu.org; Tue, 13 May 2014 08:49:45 -0400 Content-Disposition: inline In-Reply-To: <87d2fhkhcd.fsf@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Ludovic Court??s Cc: guix-devel On Tue, May 13, 2014 at 02:12:34PM +0200, Ludovic Court??s wrote: John Darrington skribis: > On Tue, May 13, 2014 at 10:11:41AM +0200, Ludovic Court??s wrote: > Before commit ab6a279, /etc/{group,passwd,shadow} were all created from > a derivation. Thus, /etc contained symlinks to those files, which were > actually in the store. Being in the store, they were all immutable and > world-readable (you can see that in the VM image released with 0.6.) > > That was obviously not desirable, because then everyone can read shadow, > and because that prevents passwords from being changed. > > So commit ab6a279 changed accounts to be created at ???activation > time??????i.e., when booting, or when switching to a new operating system > configuration. What happens is that the activation code checks for all > the user accounts and groups required by the ???operating-system??? > declaration, and invokes ???useradd??? and ???groupadd??? for any missing > account/group. > > That way, {group,passwd,shadow} are normal state files with the right > permissions, and everything works as expected. NixOS uses the same > strategy. > > > Does /etc/group now have a "nogroup" group? No, but it???d be a useful addition. > I was trying to package up GNU cssc, but one of its tests relies on > having a group which no user is a member of. Ah, but that???s a different story: you???re referring to the build environment, whereas I was talking about the operating system declarative configuration, for use in the stand-alone system (info "(guix) System Configuration"). Regarding the build environment, maybe it makes sense to add ???nogroup??? as well; not completely sure. Any pointers as to how ubiquitous it is, or other arguments? It's probably not too ubiquitous, but one other argument, is that there is already a "nobody" in the build environment's /etc/passwd. For consistency there should be a nogroup in /etc/group J' -- PGP Public key ID: 1024D/2DE827B3 fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://sks-keyservers.net or any PGP keyserver for public key.