#10843 NORM Opportu: updates.laptop.org can't serve files with 000 permissions

[Zarro Boogs per Child]

#10843: updates.laptop.org can't serve files with 000 permissions
-----------------------------+----------------------------------------------
 Reporter:  dsd              |                 Owner:  dsd          
     Type:  defect           |                Status:  new          
 Priority:  normal           |             Milestone:  Opportunity  
Component:  upgrade utility  |               Version:  not specified
 Keywords:                   |           Next_action:  code         
 Verified:  0                |   Deployment_affected:               
Blockedby:                   |              Blocking:               
-----------------------------+----------------------------------------------
 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.

-- 
Ticket URL: <http://dev.laptop.org/ticket/10843>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system