20nssdatabases checks for file equivalence and don't does anything in
thie case. However nss may include more modules then just "files" and
will fail to produce a usefull result in this case.

Bastian

This is very true.

However, we are checking the file device number and inode number, not
the file contents.  These should never be the same both inside and
outside the chroot.  If they are, something is very badly wrong:

For example, 20nssdatabases does the equivalent of

  getent passwd > $chroot/etc/passwd

Now, if NSS is set up to use "files" for passwd on the host, you've
just deleted your system passwd database, since the
'> $chroot/etc/passwd' will cause the shell to truncate /etc/passwd
inside the chroot prior to running getent, which then attempt to
read an empty file: the data is gone.


I've checked for btrfs filesystems, and each subvolume has a separate
device number, so I can't see a normal situation where the system
databases would have the same device/inode combination on the host
system and inside the chroot.  In the situation where they were
deliberately bind mounted, the script would previously blank the
files due to the above situation, and this check was added as a
sanity check to prevent that occurring.

I agree that due to how the sysadmin set up the NSS that the host
files may not be useful, but in this case "getent" will still
return the contents of whatever NSS databases you are using--the
check is still just a sanity check to prevent disaster.


I hope this makes sense.  If there's something I'm overlooking and
misunderstood with your report, please do let me know.  Is your
system set up in such a way that it's preventing the databases
being copied?  If so, some more details about your setup would be
very helpful.


Regards,
Roger

and the contents of /etc/passwd are not equivalent. So in case of a
hardlinked file the result is a completely different (just it) then if
the script creates a new one (the contents all nss databases).

Okay, to be exact: getent passwd may not provide a complete view anyway
(because of query limits or so in case of remote databases, like ldap).

It have to replace the old file in this case anyway and not truncate it.

Bastian

I'm not sure I completely understand here.  I agree the contents are
different, but why do we need to care about the content of /etc/passwd
if we aren't using it?

When you're mentioning hardlinked files, what is hardlinked to what,
and why?

Do you have any suggestions as to how to better cater for this
type of setup?

the '>' operator in the shell does an ftruncate prior to fork/exec
(to set up the pipes), so when /etc/passwd is your only NSS database,
it's gone completely before getent even runs.


Regards,
Roger