Debian Bug report logs - #586195
20nssdatabases checks for file equivalence

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Bastian Blank <waldi@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: 20nssdatabases checks for file equivalence

Date: Thu, 17 Jun 2010 11:49:47 +0200

Package: schroot
Version: 1.4.4-1
Severity: normal
File: /etc/schroot/setup.d/20nssdatabases

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

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages schroot depends on:
ii  libboost-filesystem1.42.0     1.42.0-3   filesystem operations (portable pa
ii  libboost-program-options1.42. 1.42.0-3   program options library for C++
ii  libboost-regex1.42.0          1.42.0-3   regular expression library for C++
ii  libboost-system1.42.0         1.42.0-3   Operating system (e.g. diagnostics
ii  libc6                         2.11.1-3   Embedded GNU C Library: Shared lib
ii  libgcc1                       1:4.4.4-5  GCC support library
ii  liblockdev1                   1.0.3-1.4  Run-time shared library for lockin
ii  libpam0g                      1.1.1-3    Pluggable Authentication Modules l
ii  libstdc++6                    4.4.4-5    The GNU Standard C++ Library v3
ii  libuuid1                      2.17.2-3   Universally Unique ID library
ii  schroot-common                1.4.4-1    common files for schroot

schroot recommends no packages.

Versions of packages schroot suggests:
pn  aufs-modules | unionfs-module <none>     (no description available)
pn  debootstrap                   <none>     (no description available)
ii  lvm2                          2.02.66-1  The Linux Logical Volume Manager
ii  unzip                         6.0-4      De-archiver for .zip files

-- Configuration Files:
/etc/schroot/default/copyfiles changed [not included]
/etc/schroot/default/fstab changed [not included]
/etc/schroot/schroot.conf changed [not included]
/etc/schroot/setup.d/20nssdatabases changed [not included]

-- no debconf information

Message #10 received at 586195@bugs.debian.org (full text, mbox, reply):

From: Roger Leigh <rleigh@codelibre.net>

To: Bastian Blank <waldi@debian.org>, 586195@bugs.debian.org

Subject: Re: [buildd-tools-devel] Bug#586195: 20nssdatabases checks for file equivalence

Date: Sat, 26 Jun 2010 23:36:12 +0100

[Message part 1 (text/plain, inline)]

On Thu, Jun 17, 2010 at 11:49:47AM +0200, Bastian Blank wrote:
> Package: schroot
> Version: 1.4.4-1
> Severity: normal
> File: /etc/schroot/setup.d/20nssdatabases
> 
> 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.

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

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

[signature.asc (application/pgp-signature, inline)]

Message #15 received at 586195@bugs.debian.org (full text, mbox, reply):

From: Bastian Blank <waldi@debian.org>

To: Roger Leigh <rleigh@codelibre.net>

Cc: 586195@bugs.debian.org

Subject: Re: [buildd-tools-devel] Bug#586195: 20nssdatabases checks for file equivalence

Date: Sun, 27 Jun 2010 12:01:12 +0200

On Sat, Jun 26, 2010 at 11:36:12PM +0100, Roger Leigh wrote:
> On Thu, Jun 17, 2010 at 11:49:47AM +0200, Bastian Blank wrote:
> > 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.
> 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:

The problem is a completely different one: the result of getent passwd
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).

> For example, 20nssdatabases does the equivalent of
>   getent passwd > $chroot/etc/passwd

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

Bastian

-- 
Earth -- mother of the most beautiful women in the universe.
		-- Apollo, "Who Mourns for Adonais?" stardate 3468.1

Message #20 received at 586195@bugs.debian.org (full text, mbox, reply):

From: Roger Leigh <rleigh@codelibre.net>

To: Bastian Blank <waldi@debian.org>

Cc: 586195@bugs.debian.org

Subject: Re: [buildd-tools-devel] Bug#586195: 20nssdatabases checks for file equivalence

Date: Sun, 27 Jun 2010 12:10:24 +0100

[Message part 1 (text/plain, inline)]

On Sun, Jun 27, 2010 at 12:01:12PM +0200, Bastian Blank wrote:
> On Sat, Jun 26, 2010 at 11:36:12PM +0100, Roger Leigh wrote:
> > On Thu, Jun 17, 2010 at 11:49:47AM +0200, Bastian Blank wrote:
> > > 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.
> > 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:
> 
> The problem is a completely different one: the result of getent passwd
> 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).

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?

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

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

> > For example, 20nssdatabases does the equivalent of
> >   getent passwd > $chroot/etc/passwd
> 
> It have to replace the old file in this case anyway and not truncate it.

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

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.