Package: obnam Version: 1.7.4-1 Severity: normal Tags: security Imagine obnam restore running on a live system. Perhaps root is kindly restoring to /home/user/deleted-files-restored-from-yesterday/ on a multi-user system, where /home/user does not have locked down permissions, so other users can cd to that directory.
It looks to me like obnam restores each file by 1. opening a new file, using the default umask 2. writing the file's content 3. restoring the file owner's and permissions So, it seems there is a race between 2 and 3, where a file from the backup that is not world-readable, may be readable during the restore. Note that I have not verified this to be the case, so obnam could perhaps be doing something smart in step 1 to avoid it. There may also be a wider race involving the permissions of restored directories. I'm not sure. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages obnam depends on: ii libc6 2.18-4 ii python 2.7.5-5 ii python-cliapp 1.20140315-1 ii python-fuse 2:0.2.1-9 ii python-larch 1.20131130-1 ii python-paramiko 1.10.1-1 ii python-tracing 0.8-1 ii python-ttystatus 0.23-1 obnam recommends no packages. obnam suggests no packages. -- no debconf information -- see shy jo
signature.asc
Description: Digital signature
