User accounts

User accounts

[Ludovic Courtès]

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.

Ludo’.

Re: User accounts

[John Darrington]

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?  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.

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.

Re: User accounts

[Ludovic Courtès]

John Darrington <john@darrington.wattle.id.au> 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?

Ludo’.

Re: User accounts

[John Darrington]

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