Re: User accounts

[John Darrington]

On Tue, May 13, 2014 at 02:12:34PM +0200, Ludovic Court??s wrote:
     John Darrington <address@hidden> 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.