Ticket #10843 (new defect)
updates.laptop.org can't serve files with 000 permissions
|Reported by:||dsd||Owned by:||dsd|
|Component:||upgrade utility||Version:||not specified|
|Deployments affected:||Blocked By:|
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.