[Nix-dev] /etc/skel, useradd - resolve symlinks before copying?

Florian Friesdorf flo at chaoflow.net
Sat Feb 12 14:39:22 CET 2011


On Sat, Feb 12, 2011 at 12:54:41PM +0100, Marc Weber wrote:
> Background:
> 
> Whenever you (or nixos) runs useradd -m .. everything in /etc/skel is
> copied into the new users home directory.
> 
> This is usually used to setup initial .bashrc files etc.
> 
> Now NixOS is based on symlinks. Thus /etc/skel/.bashrc -> /nix/store/...
> 
> Thus ~/.bashrc -> /nix/store/...

For corectness sake, it is:
~/.bashrc -> /etc/static/skel/.bashrc

which in turn is a symlink into the store
/etc/static/skel/.bashrc -> /nix/store/...

> So the user can't edit the file which is bad.

The user owns the file and therefore could change the symlink into a
copy. A solution could be to explain in the file what to do in order to
get a copy that can be changed.

> So does it make sense to patch either useradd or the /etc generating
> script to not use symlinks so that ~/.bahsrc is a copy of /nix/store/...  ?
> 
> useradd code of shadow contains the function copy_tree so I think its
> trivial to patch.
> 
> There is one reason to keep symlinks: Whenever /etc/skel updates the
> contents of the files will update as well. However in the case of shell
> initialization files you can put in a "source /etc/.." line to achieve
> the same result - and users can use their editors and edit those files.
> 
> How do you think about it?

The content of the skel .bashrc in the store:
#!/bin/sh

if [ -f /etc/bashrc ]
then
    source /etc/bashrc
fi

Does it need to be a symlink at all or could the nix expression just
generate a file with that content in /etc/skel and make clear with a
comment not to make changes to it? If something needs to be changed for
all users, it would happen in /etc/bashrc. I don't think we need updates
of the skel bashrc.

-- 
Florian Friesdorf <flo at chaoflow.net>
  GPG FPR: 7A13 5EEE 1421 9FC2 108D  BAAF 38F8 99A3 0C45 F083
Jabber/XMPP: flo at chaoflow.net
IRC: chaoflow on freenode,ircnet,blafasel,OFTC



More information about the nix-dev mailing list