[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