Bug 6178 - (int-147085) Files not readable by user are not backed up - data loss
(int-147085)
: Files not readable by user are not backed up - data loss
Status: NEW
Product: Settings and Maintenance
Backup/Restore
: 5.0:(20.2010.36-2)
: N900 Maemo
: Low critical with 4 votes (vote)
: ---
Assigned To: unassigned
: backup-restore-bugs
:
:
:
:
  Show dependency tree
 
Reported: 2009-11-14 21:35 UTC by Andrea Borgia
Modified: 2010-10-26 11:37 UTC (History)
6 users (show)

See Also:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description Andrea Borgia (reporter) 2009-11-14 21:35:16 UTC
SOFTWARE VERSION:
1.2009.41-10

STEPS TO REPRODUCE THE PROBLEM:
1. install openvpn from fremantle extras-devel
2. create a backup
3. wipe device clean & restore from backup or manually check zip contents

EXPECTED OUTCOME:
All files under /etc/openvpn are restored from the backup: abo-n900.crt,
abo-n900.key, ca.crt, casa-andrea.conf, maemo-update-resolvconf,
router-casa-andrea.crt

ACTUAL OUTCOME:
Only the following files are present in the backup:
router-casa-andrea.crt, maemo-update-resolvconf, casa-andrea.conf

REPRODUCIBILITY:
always

EXTRA SOFTWARE INSTALLED:
openvpn, unzip

OTHER COMMENTS:
The problem was present in a similar form also in Diablo: in that case, some
files would be backed up but not restored.

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; it; rv:1.9.1.5)
Gecko/20091109 Ubuntu/9.10 (karmic) Firefox/3.5.5
Comment 1 Lucas Maneos 2009-11-15 10:56:36 UTC
Caused by "user" not having read permission on the missing files.  I can
reproduce this as follows:

1. Create /etc/osso-backup/applications/test.conf containing:
   <backup-configuration>
     <locations>
       <location type="dir" category="settings">/home/user/test</location>
     </locations>
   </backup-configuration>
2. Create and populate /home/user/test with some files not readable by user:
   $ mkdir /home/user/test
   $ for i in A B C D ; do touch /home/user/test/$i; done
   # for i in A B; do chown root /home/user/test/$i; chmod 400
/home/user/test/$i; done
3. Create a new backup called "test", selecting settings (the other stuff is
irrelevant)
4. unzip -l /home/user/MyDocs/backups/test/settings.zip | grep
Root/home/user/test

Outcome: C and D are present in the backup, A and B are missing.

I'm not sure what the right solution would be (probably not making osso-backup
suid root), but backup should at least warn the user when it fails to back up a
file that it's supposed to instead of pretending everything was backed up and
causing data loss.  Increasing severity accordingly.

This permissions issue is not mentioned in
<http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Generic_Platform_Components/Using_Backup_Application>
so I would also condider it a documentation bug.
Comment 2 Josef Assad 2009-11-15 15:51:19 UTC
For a non-technical user, I don't think there's a win-win way of advising that
osso-backup has a problem. If the notification explains which files it would
get confusing. If it just explains that for example "not all files could be
backed up" then this doesn't really help the user fix anything or figure out
what to do accordingly.

I don't like having too much stuff setuid root either, but doesn't backup
software usually run as root anyhow?

Doesn't lintian perform permissions checks? Perhaps a lintian pass policy for,
say, Extras would mitigate this problem.
Comment 3 Lucas Maneos 2009-11-15 16:35:56 UTC
(In reply to comment #2)
> For a non-technical user, I don't think there's a win-win way of advising that
> osso-backup has a problem. If the notification explains which files it would
> get confusing.

It would at least give the user a change to back those files up via other means
before doing anything destructive like restoring original settings or flashing
a new firmware image.

Note that this isn't something users would be normally expected to face. 
If/when it happens it is a bug that should be fixed.

> Doesn't lintian perform permissions checks? Perhaps a lintian pass policy for,
> say, Extras would mitigate this problem.

In this particular case at least the missing files did not come from a .deb so
lintian wouldn't help.  A similar case would be /etc/ssh/ssh_host_[dr]sa_key. 
And of course there are valid reasons for not having certain files
world-readable (although perhaps less important on a single-user distribution).
Comment 4 timeless 2009-11-15 22:58:25 UTC
this can be solved using:
/etc/osso-backup/(pre|post|restore)-backup.d/

how you choose to use this is up to you.

Backup's documentation for /etc/osso-backup/ should cover this.

One approach is breaking permissions for pre, restoring them in post, and
restoring them in restore. There are others.
Comment 5 Lucas Maneos 2009-11-16 03:21:43 UTC
(In reply to comment #4)
> this can be solved using:
> /etc/osso-backup/(pre|post|restore)-backup.d/

Aha, thanks for the tip!  Something like that did cross my mind, but the
aforementioned wiki page only talks about /etc/osso-backup/restore.d/ which
wouldn't be enough.

> Backup's documentation for /etc/osso-backup/ should cover this.

I agree, but the Fremantle doc looks like a straight copy from Chinook
(<http://maemo.org/development/documentation/tutorials/maemo_4-0_tutorial/#backup>)
/ Diablo
(<http://maemo.org/maemo_release_documentation/maemo4.1.x/node8.html#SECTION00860000000000000000>)
and if there is any more complete documentation somewhere I haven't managed to
find it :-(  Any pointers, or should I file a docs bug for this?

> One approach is breaking permissions for pre, restoring them in post, and
> restoring them in restore. There are others.

Do you know whether the pre/post scripts run with root or user privileges?  The
ones already there seem to reference $HOME a lot (suggesting user), but I
suppose there could be some sudo (which keeps the previous $HOME value) magic
happening at restore time.
Comment 6 Eero Tamminen nokia 2009-11-18 12:35:06 UTC
> Do you know whether the pre/post scripts run with root or user privileges? 

dpkg and anything it runs at package installation time are run as root.


Maybe there could be a separate bug about the documentation issue?
Comment 7 Lucas Maneos 2009-11-18 12:50:31 UTC
(In reply to comment #6)
> dpkg and anything it runs at package installation time are run as root.

Sorry if I wan't clear, I meant the osso-backup scripts
(/etc/osso-backup/{pre-backup,post-backup,restore}.d).  Since the files in
question here are not packaged dpkg won't help.

To answer my own question, the first two are easy to test quickly, by creating
dummy scripts that touch a file in /tmp, which results in:

-rw-r--r--    1 user     users           0 Nov 18 10:44 post-backup
-rw-r--r--    1 user     users           0 Nov 18 10:43 pre-backup

so the solution proposed in comment 4 won't work.

> Maybe there could be a separate bug about the documentation issue?

Sure, I'll try to file one tonight but if anyone wants to beat me to it feel
free :-)
Comment 8 Josef Assad 2009-11-18 13:07:50 UTC
(In reply to comment #7)
> (In reply to comment #6)
> To answer my own question, the first two are easy to test quickly, by creating
> dummy scripts that touch a file in /tmp, which results in:
> 
> -rw-r--r--    1 user     users           0 Nov 18 10:44 post-backup
> -rw-r--r--    1 user     users           0 Nov 18 10:43 pre-backup
> 
> so the solution proposed in comment 4 won't work.

Maybe those scripts in /etc/osso-backup should run as root but preserve
ownership then?
Comment 9 Lucas Maneos 2009-11-19 11:01:50 UTC
Documentation out-of-date issue filed as bug 6250.
Comment 10 Urho Konttori 2010-03-10 16:52:11 UTC
this is clearly an issue in the application itself, not in backup.
Comment 11 Lucas Maneos 2010-03-11 09:55:12 UTC
(In reply to comment #10)
> this is clearly an issue in the application itself, not in backup. 

I respectfully disagree.  There are very good reasons for having files like
openvpn or openssh secret keys only readable by root, and osso-backup does not
provide a mechanism for backing those up.  The only workarounds from the
package side I can think of are:

1) create those files with permissions/ownership so that they are readable by
user, or 
2) install some helper scripts and add them to sudoers so that they can be
started by osso-backup scripts with root permissions

but both of these leave the sensitive files wide open to any user-owned process
and may even introduce new security issues.
Comment 12 Andrea Borgia (reporter) 2010-03-21 13:09:02 UTC
Andre, could you check the contents of int-147085  ?

I feel strongly that the reassignment of this report to OpenVPN is incorrect
since I am using a system facility and there is no applicable workaround.
Comment 13 Andre Klapper maemo.org 2010-04-15 18:08:07 UTC
(In reply to comment #12)
> Andre, could you check the contents of int-147085  ?
> I feel strongly that the reassignment of this report to OpenVPN is incorrect
> since I am using a system facility and there is no applicable workaround.

There are no comments in int-147085.

(In reply to comment #10)
> this is clearly an issue in the application itself, not in backup. 

Urho, please elaborate why you think so.
Comment 14 Andrea Borgia (reporter) 2010-10-26 11:37:10 UTC
Upgraded to PR1.3 via backup, flash, restore and the issue is still there.