I tried using Perl's chown with getpwnam/getgrnam, but getpwnam "root" and getgrnam "shadow" didn't work... So, I had to use system and call out to the chown binary.

@volth or @stigtsp any interest in taking a look at this?

FWIW, the problem was that the script would say Argument "root" isn't numeric in chown at .... when doing:

chown getpwnam "root", getgrnam "shadow", "/etc/shadow";

So, for some reason, getpwnam "root" and getgrnam "shadow" aren't resolving the numeric ids.

Ah, I think I found my problem: if I use my $uid = getpwnam "root";, $uid becomes the $uid returned by the list of getpwnam (same for $gid).

Now this can be totally in Perl :)

EDIT: I put it in a scope because I saw $gid and $uid used elsewhere and didn't want to affect those (if it's even possible to do so). I can remove that if desired.

chown getpwnam "root", getgrnam "shadow", "/etc/shadow";

This might be because getpwnam and getgrnam are called in list context sending a list of 10 items to chown:

perl -MData::Dumper -E 'say Dumper getpwnam "root", getgrnam "shadow", "/etc/shadow"'
$VAR1 = 'root';
$VAR2 = 'x';
$VAR3 = 0;
$VAR4 = 0;
$VAR5 = '';
$VAR6 = '';
$VAR7 = 'System administrator';
$VAR8 = '/root';
$VAR9 = '/run/current-system/sw/bin/bash';
$VAR10 = '/etc/shadow';

As you point out, the patch with my $uid = getpwnam "root"; calls it in scalar context which returns what's expected. :)

$ perldoc -f getpwnam
[..]        
            In scalar context, you get the name, unless the function was a
            lookup by name, in which case you get the other thing, whatever
            it is. (If the entry doesn't exist you get the undefined value.)
[..]

ADD: Scoping $uid and $gid is reasonable, since it makes it clear that the variables are not used elsewhere.

@ofborg eval

(I think I broke it by force-pushing too fast :P)

@ofborg test installer.simple

Hi! I just encountered the issue that this PR solved when I was using a bit old nixpkgs version. I now used this patch to fix the issue, thanks! However, I'm wondering why the permissions are still kept at 0600 instead of 0640? I would have expected this patch to give read-access to /etc/shadow file for the group, what's the purpose of setting the group otherwise? So, probably I'm missing something and I'd like to understand. Thanks for help!

Just an oversight. I'd happily accept a PR fixing that :)

PR opened: #116644