[Server-devel] Issue with ds-backup in XS 0.4

[Bill Bogstad]

Okay, I've found the problem with the XO that was failing to backup
and it may imply some issues with older XO releases...

Instead of enabling logging for the cron entry, I copied the
ds-backup.sh script and modified it to not delay and to run
/usr/bin/ds-backup.py explicitly.
ds-backup.py output error messages from ssh complaining about bad
permissions on the ssh key files.

Here are the permissions on the failing machine:

[olpc at xo-0D-0B-73 default]$ ls -l ~olpc/.sugar/default/owner*
-rwxr-xr-x 1 olpc olpc 668 2007-12-26 03:01 /home/olpc/.sugar/default/owner.key
-rwxr-xr-x 1 olpc olpc 590 2007-12-26 03:01
/home/olpc/.sugar/default/owner.key.pub

And here's the working machine:
-bash-3.2# ls -l ~olpc/.sugar/default/owner*
-rw------- 1 olpc olpc 668 2008-10-15 00:07 /home/olpc/.sugar/default/owner.key
-rw-r--r-- 1 olpc olpc 590 2008-10-15 00:07
/home/olpc/.sugar/default/owner.key.pub

The failing machine shows overly permissive permissions on the key
files.  In particular, ds-backup.py generated the following message
when it failed:

__main__.TransferError: ('rsync error code 12, message:',
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@\r\n@
   WARNING: UNPROTECTED PRIVATE KEY FILE!
@\r\n@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@\r\nPermissions
0755 for '/home/olpc/.sugar/default/owner.key' are too open.\r\nIt is
recommended that your private key files are NOT accessible by
others.\r\nThis private key will be ignored.\r\nbad permissions:
ignore key: /home/olpc/.sugar/default/owner.key\r\nPermission denied
(publickey).\r\nrsync: connection unexpectedly closed (0 bytes
received so far) [sender]\nrsync error: error in rsync protocol data
stream (code 12) at io.c(635) [sender=3.0.3]\n")

I believe that ssh has long had checks which disallow use of key files
which are world readable.  If anyone could read your private key file
then they could attempt to brute force your passphrase.   In this
case, I don't think the private key file even has a passphrase which
makes it even worse.  SSH is unaware of the OLPC's single user
environment.  I changed the permission on the key files to match those
of the machine that works and was able successfully complete a backup
to my XS schoolserver.

The open question is how did the keyfiles get those permissions on the
bad machine? You'll note that the mod time of the file is around
Christmas 2007.  The XO in question was a gift to my daughter and it's
entirely plausible that is when it was first turned on and setup.  I'm
not 100% sure that the machine wasn't reflashed, but based on the date
I doubt it.  This would seem to indicate that somehow the permissions
were set wrong from the moment the keys were generated.   I have a
third G1G1 which is still running the 703 build (my other daughter's
machine). I just checked and the permissions on her key files are also
bad.  The modtime is within a couple of minutes of the other bad
machine.  This would strongly incline me to believe that the
permissions problem was something in the original G1G1 XO install
image.  On the other hand, I just checked trac and there have been
issues in the past with olpc-update changing permissions in ways that
ssh didn't like.

A survey of large number of XOs in the field and/or test
installs/updates using old XO images might be a good idea.  If there
is a latent bug
in many deployed machines which causes backups to fail, it would be a
good idea to know.  I'm not inclined to sacrifice my XO installs
(particularly not my daughter's machines), but could certainly work
with people at 1CC on this.  I might even be able to stop by to help
with the test installs...

Bill Bogstad