updates.laptop.org can't serve files with 000 permissions

[dsd]

Somewhere after Fedora 11, files such as /etc/shadow got reduced to having 000 permissions.

As 000 files can't be read by non-root users, updates.laptop.org can't serve them (as it runs rsync as non-root), meaning that olpc-update fails with a "Permission denied" error.

updates.laptop.org does run in a fakeroot environment, but this meets an interesting condition: tar creates the zero-permission files with open() or openat(), and fakeroot doesn't catch those functions.

The XS runs a similar system in its updates server which would face the same issue.

I wrote some code (not quite working, but probably not far off) to add the relevant code to fakeroot, but then I encountered the note in the fakeroot man page:

       open()/create()
              fakeroot  doesn't  wrap open(), create(), etc. So, if user joost
              does either

              touch foo
              fakeroot
              ls -al foo

              or the other way around,

              fakeroot
              touch foo
              ls -al foo

              fakeroot has no way of knowing that in the first case, the owner
              of  foo  really  should be joost while the second case it should
              have been root.  For the Debian packaging, defaulting to  giving
              all "unknown" files uid=gid=0, is always OK. The real way around
              this is to wrap open() and  create(),  but  that  creates  other
              problems, as demonstrated by the libtricks package. This package
              wrapped many more functions, and tried to do  a  lot  more  than
              fakeroot .  It turned out that a minor upgrade of libc (from one
              where the stat() function didn't use open() to one with a stat()
              function that did (in some cases) use open()), would cause unex-
              plainable segfaults  (that  is,  the  libc6  stat()  called  the
              wrapped  open(),  which  would then call the libc6 stat(), etc).
              Fixing them wasn't all that easy, but once fixed, it was just  a
              matter  of  time  before another function started to use open(),
              never mind trying to port it to a  different  operating  system.
              Thus  I decided to keep the number of functions wrapped by fake-
              root as small as possible, to limit the  likelihood  of  `colli-
              sions'.

so this is deliberate, I'm probably barking up the wrong tree. (will email fakeroot maintainers just to check)

To solve this, we could move away from using fakeroot, to using rsync's fake-super. Tar (or Python's tarfile module) would extract the files, applying permissions and ownership in the form of rsync's special extended attributes, then rsyncd would run with fake super mode.

After losing some time working on fakeroot, for now I'm going to take the easy approach and filter the build, changing 000 files to 400.

[pgf]

Replying to dsd:

After losing some time working on fakeroot, for now I'm going to take the easy approach and filter the build, changing 000 files to 400.

especially reasonable on a machine with an empty root password. :-)