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

[Marc Weber]

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

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

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?

Marc Weber

[Florian Friesdorf]

Post by Marc Weber
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/...

Post by Marc Weber
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.

Post by Marc Weber
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.

[Lluís Batlle i Rossell]

Post by Florian Friesdorf
#!/bin/sh
if [ -f /etc/bashrc ]
then
source /etc/bashrc
fi

Is this really needed? Isn't bash always sourcing /etc/bashrc if it exits? Maybe
we better don't keep any .bashrc at all in the skel.

[Marc Weber]

Sometimes I create an SSH account for customers to create web previews.
Most of them don't even know bash. So I want my defaults to be available
everywhere without additional efforts - "Do it once".

I konw that some people hate defaults. So opting out by putting
your own contents into ~/.bashrc seems to be the perfect way.

In my patch /etc/bashrc *only* sets up PATH - because this is special
about nixos - and without PATH you can't work.

I moved all the colored ls alias stuff etc into
/etc/bash-user-system-default.sh and make the ~/.bashrc source it.

This way its always up to date if nobody cared about it.

Its no only about ~/.bashrc. Its also about ~/.vimrc. Touching it is
enough to force "nocompatbile" mode which is the mode you want to work
in - because without it ever :e fil<tab> completion doesn't work.

Again: I want users being able to change the default - without having to
remove the symlink first.

The real question is: Patch the /etc builder script and make it have
some additional bookkeeping or patch useradd.

Patching useradd seems to be the cleaner solution to me so that's what
I'm going to do.

Its not much what I want: only git completion and a faster cd command.

That's what I'm putting into my new nixos configuration option called
interactiveShellInit

If you think about it you're very likely to find some use cases for
additional commands you want to support system wide.

Marc Weber

[Marc Weber]

Post by Florian Friesdorf
Does it need to be a symlink at all or could the nix expression just
generate a file

Of course it can.
Have a look at nixos/modules/system/etc/setup-etc.pl

# Remove dangling symlinks that point to /etc/static. These are
# [..]
sub cleanup {

So files won't dangle. So you have to do extra book keeping then.
That's why I suggested patching useradd instead.

Marc Weber

[Florian Friesdorf]

Post by Marc Weber

Post by Florian Friesdorf
Does it need to be a symlink at all or could the nix expression just
generate a file

Of course it can.
Have a look at nixos/modules/system/etc/setup-etc.pl
# Remove dangling symlinks that point to /etc/static. These are
# [..]
sub cleanup {
So files won't dangle. So you have to do extra book keeping then.
That's why I suggested patching useradd instead.

+1

[Michael Raskin]

Post by Marc Weber
Now NixOS is based on symlinks. Thus /etc/skel/.bashrc -> /nix/store/...
Thus ~/.bashrc -> /nix/store/...
So the user can't edit the file which is bad.

I agree - I think we should simply build /etc/skel by copying,
just like we copy some other things in activation scripts

[Marc Weber]

Excerpts from Michael Raskin's message of Sat Feb 12 17:02:42 +0100

Post by Michael Raskin
I agree - I think we should simply build /etc/skel by copying,
just like we copy some other things in activation scripts

How do you want to "tidy up"?

Example:

current-system: /etc/static/skel/.vimrc

new-system: no longer any .vimrc

Should the activation script remove /etc/skel/.vimrc then?

If so you have to keep track of it, corret?
Which would be the best way to do that?

Use an /etc/nix-managed-files file and register all files there?
Then after updating /etc/ compare old and new nix-managed-files
so that you know which files to remove?

Marc Weber

[Michael Raskin]

Post by Marc Weber
Excerpts from Michael Raskin's message of Sat Feb 12 17:02:42 +0100

Post by Michael Raskin
I agree - I think we should simply build /etc/skel by copying,
just like we copy some other things in activation scripts

How do you want to "tidy up"?
current-system: /etc/static/skel/.vimrc
new-system: no longer any .vimrc
Should the activation script remove /etc/skel/.vimrc then?
If so you have to keep track of it, corret?
Which would be the best way to do that?

We already had activation scripts scan /etc/ for stale links into /etc/static with
the goal of removing these links. It seems an OK decision for /etc/skel

[Marc Weber]

Post by Michael Raskin
We already had activation scripts scan /etc/ for stale links into /etc/static with
the goal of removing these links. It seems an OK decision for /etc/skel

In the past there was a sh script - now it seems to be a perl script.
See my previous mail - I quoted the important part of the documentation.

You said "copy" - So i thought you were referring to
cp (readlink /etc/static/skel/.bashrc) /etc/skel

However removing "stale" files doesn't work - because files can't be
stale ?

I want plain files in ~. So I have to put plain files into /etc/skel or
patch copy_tree in useradd.

I feel like repeating myself - so maybe I missunderstood you this time.

Marc Weber

[Michael Raskin]

Post by Marc Weber

Post by Michael Raskin
We already had activation scripts scan /etc/ for stale links into /etc/static with
the goal of removing these links. It seems an OK decision for /etc/skel

In the past there was a sh script - now it seems to be a perl script.
See my previous mail - I quoted the important part of the documentation.
You said "copy" - So i thought you were referring to
cp (readlink /etc/static/skel/.bashrc) /etc/skel
However removing "stale" files doesn't work - because files can't be
stale ?

Hm. I probably forgot to think well before posting.

You are right, keeping track is needed. Not that it is complex.

Your idea about having a list in a file can be amended with the word "sorted",
so simple diff fed to "xargs rm" will be possible.

Removals from skel should also be rare.

Post by Marc Weber
I want plain files in ~. So I have to put plain files into /etc/skel or
patch copy_tree in useradd.
I feel like repeating myself - so maybe I missunderstood you this time.

No, it is me being stupid.

[Marc Weber]

Post by Michael Raskin
Your idea about having a list in a file can be amended with the word "sorted",
so simple diff fed to "xargs rm" will be possible.

If you have time also reflect that you didn't miss the second way to
solve this:

patch useradd. If something points to /etc/static don't copy symlink
into ~ - but the file it points to.

Then the /etc builder would not have to be changed - and removing of
stale files would also work without additional change.

Currently I prefer this way because it would be less work.

Marc Weber

[Michael Raskin]

Post by Marc Weber

Post by Michael Raskin
Your idea about having a list in a file can be amended with the word "sorted",
so simple diff fed to "xargs rm" will be possible.

If you have time also reflect that you didn't miss the second way to
patch useradd. If something points to /etc/static don't copy symlink
into ~ - but the file it points to.

I didn't miss that solution, I just don't know whether useradd is
the only code path interested in the exact contents of /etc/skel

[Marc Weber]

Post by Michael Raskin
I didn't miss that solution, I just don't know whether useradd is
the only code path interested in the exact contents of /etc/skel

As always: I'll change my mind if you find a second important application .. :)

patch attached - works for me

Marc Weber