Debian Bug report logs - #898287
disorderfs: inodes returned by getdents are all the same value

Toggle useless messages

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

From: Omar Navarro Leija <omarsa@seas.upenn.edu>

To: submit@bugs.debian.org

Subject: Subject: disorderfs inode on getdents

Date: Wed, 9 May 2018 14:58:25 -0400

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

Package: disorderfs
Version: 0.5.2
Severity: [normal]

When using disorderfs the inodes returned by a system call to getdents are
all the same value:
> disorderfs Getdents/ disorder/
disorderfs: reversing dirents
> cd disorder/
disorder ) ./getdents
--------------- nread=80 ---------------
*i-node#*  file type  d_reclen  d_off   d_name
*4294967295*  ???          24         32  ..
*4294967295*  ???          24         64  .
*4294967295*  ???          32         96  getdents

*getdents *is a tiny C program copied from the man 2 getdents example at
the bottom.

Meanwhile stat correctly returns a unique inode:
> stat getdents
  File: getdents
  Size: 8512          Blocks: 25         IO Block: 4096   regular file
Device: 30h/48d    *Inode: 2*           Links: 1
...
disorder ) stat .
  File: .
  Size: 4096          Blocks: 9          IO Block: 4096   directory
Device: 30h/48d    *Inode: 1*           Links: 2

This leads to an inconsistent state between inodes as well as breaking
assumptions programs might make about unique inodes when checking the
results of getdents.

[Message part 2 (text/html, inline)]

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

From: Chris Lamb <lamby@debian.org>

To: Omar Navarro Leija <omarsa@seas.upenn.edu>, 898287@bugs.debian.org, submit@bugs.debian.org

Subject: Re: Bug#898287: Subject: disorderfs inode on getdents

Date: Wed, 09 May 2018 23:12:55 +0100

Hi Omar,

> When using disorderfs the inodes returned by a system call to getdents are
> all the same value
[…]
> This leads to an inconsistent state between inodes as well as breaking
> assumptions programs might make about unique inodes when checking the
> results of getdents.

Heh. How did you spot this? Or rather, what application/foo makes
these assumptions?

(Just curious. I mean, we use disorderfs a *lot* in the reproducible
builds project and don't appear to have hit this before.)


Best wishes,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org / chris-lamb.co.uk
       `-

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

From: Chris Lamb <lamby@debian.org>

To: 898287@bugs.debian.org

Cc: Omar Navarro Leija <omarsa@seas.upenn.edu>

Subject: Re: disorderfs: inodes returned by getdents are all the same value

Date: Thu, 10 May 2018 02:02:17 +0100

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

Hi,

> disorderfs: inodes returned by getdents are all the same value

A (failing) testcase for this is attached:

  commit e68198332d3f98faa05f3f49cb0f22ad60cd1e74
  Author: Chris Lamb <lamby@debian.org>
  Date:   Wed May 9 18:00:23 2018 -0700
  
      Add (failing) testcase for inode numbering.
     tests/inodes | 100 +++++++++++++++++++++++++++++++++++++++++++++
   1 file changed, 100 insertions(+)

The current output is, as expected:

  target/.: inode from getdents does not match stat (4294967295 != 1)
  target/b: inode from getdents does not match stat (4294967295 != 2)
  target/b: duplicate inode (4294967295 already used by target/.)
  target/c: inode from getdents does not match stat (4294967295 != 3)
  target/c: duplicate inode (4294967295 already used by target/b)
  target/a: inode from getdents does not match stat (4294967295 != 4)
  target/a: duplicate inode (4294967295 already used by target/c)

Regards,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org / chris-lamb.co.uk
       `-

[0001-Add-failing-testcase-for-inode-numbering.patch (text/x-diff, attachment)]

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

From: Omar Navarro Leija <omarsa@seas.upenn.edu>

To: Chris Lamb <lamby@debian.org>

Cc: 898287@bugs.debian.org, submit@bugs.debian.org

Subject: Re: Bug#898287: Subject: disorderfs inode on getdents

Date: Thu, 10 May 2018 09:47:48 -0400

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

Hello,

I'm currently leading a research project on deterministic execution of
programs. We're developing a tool to enforce determinism dynamically on
arbitrary code. Inodes are a easy way to uniquely identify files within our
execution, so our runtime virtualizes inodes by mapping them to unique
deterministic values, and I noticed inconsistencies from the results of
getdents, getdents64 vs stat.


On Wed, May 9, 2018 at 6:12 PM, Chris Lamb <lamby@debian.org> wrote:

> Hi Omar,
>
> > When using disorderfs the inodes returned by a system call to getdents
> are
> > all the same value
> […]
> > This leads to an inconsistent state between inodes as well as breaking
> > assumptions programs might make about unique inodes when checking the
> > results of getdents.
>
> Heh. How did you spot this? Or rather, what application/foo makes
> these assumptions?
>
> (Just curious. I mean, we use disorderfs a *lot* in the reproducible
> builds project and don't appear to have hit this before.)
>
>
> Best wishes,
>
> --
>       ,''`.
>      : :'  :     Chris Lamb
>      `. `'`      lamby@debian.org / chris-lamb.co.uk
>        `-
>

[Message part 2 (text/html, inline)]

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

From: Chris Lamb <lamby@debian.org>

To: 898287@bugs.debian.org

Cc: Omar Navarro Leija <omarsa@seas.upenn.edu>

Subject: Re: disorderfs: inodes returned by getdents are all the same value

Date: Thu, 10 May 2018 15:30:08 +0100

tags 898287 + pending
thanks

Fixed in Git, with testcase.. Now ending upload:

  https://anonscm.debian.org/git/reproducible/disorderfs.git/commit/?id=39e29c4ef96319a4c716832a73ad5fd62ed9ff75

  disorderfs.cpp | 13 +++++----
  tests/inodes   | 87 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  2 files changed, 95 insertions(+), 5 deletions(-)


Regards,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org / chris-lamb.co.uk
       `-

Message #44 received at 898287-close@bugs.debian.org (full text, mbox, reply):

From: Chris Lamb <lamby@debian.org>

To: 898287-close@bugs.debian.org

Subject: Bug#898287: fixed in disorderfs 0.5.3-1

Date: Sat, 12 May 2018 17:19:32 +0000

Source: disorderfs
Source-Version: 0.5.3-1

We believe that the bug you reported is fixed in the latest version of
disorderfs, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 898287@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Chris Lamb <lamby@debian.org> (supplier of updated disorderfs package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Sat, 12 May 2018 18:02:30 +0100
Source: disorderfs
Binary: disorderfs
Architecture: source amd64
Version: 0.5.3-1
Distribution: unstable
Urgency: medium
Maintainer: Reproducible builds folks <reproducible-builds@lists.alioth.debian.org>
Changed-By: Chris Lamb <lamby@debian.org>
Description:
 disorderfs - FUSE filesystem that introduces non-determinism
Closes: 898287
Changes:
 disorderfs (0.5.3-1) unstable; urgency=medium
 .
   [ Chris Lamb ]
   * Ensure readdir(2) returns consistent/unique inode numbers.
     (Closes: #898287)
   * disorderfs.1.txt:
     - Add a reproducible builds example, highlighting the non-intuitive
       recommendation to sort instead of shuffle.
     - Correct explictly -> explicitly typo.
     - Add example on how to unmount to manpage.
   * Override no-upstream-changelog Lintian warning as we are upstream.
   * Use HTTPS format URI in debian/copyright.
   * Bump Standards-Version to 4.1.4.
   * Move to debhelper compat level 11.
   * Drop trailing whitespace in debian/control.
 .
   [ Holger Levsen ]
   * d/control: Declare that disorderfs doesn't need root to build.
Checksums-Sha1:
 7bef2470f669b4274659f13dbedfa8da244bdda5 2194 disorderfs_0.5.3-1.dsc
 936567e9dd65d7c701414b3b375092e20c1155dc 21099 disorderfs_0.5.3.orig.tar.gz
 9044ea6fe616cf33c1561d448b3b1a697341b13c 13116 disorderfs_0.5.3-1.debian.tar.xz
 dfa487def04323a0e09c51cf9c2e3e2a359253c8 129456 disorderfs-dbgsym_0.5.3-1_amd64.deb
 54f34f2b802ed16889ac95854444e72d68e70578 6713 disorderfs_0.5.3-1_amd64.buildinfo
 104912529d11509ee2c3b2d30d8bcda0a99ac7df 21400 disorderfs_0.5.3-1_amd64.deb
Checksums-Sha256:
 62f79ab925f8da8ffbb5e5553c4d37fb8b1e6d5acac773abfd13ea2cdd868ffb 2194 disorderfs_0.5.3-1.dsc
 d8b61daf8af213b025c1f1e1c4fe44dd7c9a288f69ea524a898c39ce1011a6ff 21099 disorderfs_0.5.3.orig.tar.gz
 119d4b074c240d812a7c45aec287956691213fc6615651633317a510dd6dda00 13116 disorderfs_0.5.3-1.debian.tar.xz
 801f2d98420d9625daec4daa40083a429574cabd5684665dfd8b9e2eb754847d 129456 disorderfs-dbgsym_0.5.3-1_amd64.deb
 8f3586b733da9dc3e97d694cc86e709b660aa51bd31bd52e534e71be780f6145 6713 disorderfs_0.5.3-1_amd64.buildinfo
 14f8571b531fb0aea6edbdfe6721e4add35eaec98a7093e06677f942fffa4e8c 21400 disorderfs_0.5.3-1_amd64.deb
Files:
 ac4435012d34e0bb9e4639b9c6308da0 2194 utils optional disorderfs_0.5.3-1.dsc
 d98cfea436b8560ba1ca15931670ccc7 21099 utils optional disorderfs_0.5.3.orig.tar.gz
 e676c23b8a6d310692097b7990ee31cb 13116 utils optional disorderfs_0.5.3-1.debian.tar.xz
 977baf16e93ebffbb89b03533e94d13a 129456 debug optional disorderfs-dbgsym_0.5.3-1_amd64.deb
 ccad3916e01c73223fe34850f7d53979 6713 utils optional disorderfs_0.5.3-1_amd64.buildinfo
 a58bf9d2e3a5cecd1bf500a746d9d8c2 21400 utils optional disorderfs_0.5.3-1_amd64.deb

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEwv5L0nHBObhsUz5GHpU+J9QxHlgFAlr3H6EACgkQHpU+J9Qx
Hli1cw//Yz7X4luykZCH3zg/qWftd1Mv/doqpcGXm2x68YfoO6qlznmz0i2d2n2q
UoyDr98cSgYckCRGOOQkxl55mFqzcxGCb2a6MZ62vdqeObh3x6anR6BLzHMZPnHx
ftrwVOo8S7aDhYzapcyqDZfZah96VIcMAQeDT6F4Ueuli+5J3vpDqu2YsZmQ7nJu
mgAdOVsP85qOvQ4l0HgBPimZd+O1g81sd31oij8B50XCgQGVa+jayqNvK9G+oIRM
7vqasX3J9G7HNRW68DP+CQ229Uhegb6P7rw8LopneQFu3+y70n7b1eiWHM4hdBd3
RtDBdhhimZ6NF/W0cEGvSeMjL4T0ZYDcHkfPpIufB6tbe9yuNsG8d0/TDMZibVaQ
RJA3A/2sesRGyPUVlxIzjexI4DYYLiqILX9uiqbo5Z0/v0f7BaL+Kboy3jnY9AEF
d/ZBAcRr3sluB+DYvCdoGRlFJp3QbgTt7EIHQkcyzDxrefVwAd1K2HXphDm9hT/8
+boa8dBE+w4bS4ahq0cLLzDlHD/ZocLwelAWvOYgYq4dY2sUPZsl9v2/ygSeKuz/
aCfpPszzr/drh6mjoW42o0q0B1EFkgSdA8B/2GypjbY3kMo6P0wItZgMjZx5HI8E
2pfxCdZUZ+G190NzlAE8O3UEo9xlIaxwRu/9iMnDauTt6RIXH+g=
=gRKA
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.