Restore a symlink changes target attributes

[Samuel Bancal]

Hi,

Using --file-to-restore option on a symlink, I've found that it changes the mod (644->777) of the target file.

Technical infos :
duplicity 0.6.17
Python 2.6.5
Ubuntu 10.04.3
Target FileSystem : ext4

Steps to reproduce it :

$ mkdir -p ~/tmp/duplicity
$ cd ~/tmp/duplicity/
$ touch ~/tmp/fooo
$ ln -s ~/tmp/fooo fooo
$ ls -l ~/tmp/fooo fooo
lrwxrwxrwx 1 bancal bancal 21 2012-02-10 14:33 fooo -> /home/bancal/tmp/fooo
-rw-r--r-- 1 bancal bancal 0 2012-02-10 14:32 /home/bancal/tmp/fooo

$ duplicity --no-encryption /home/bancal/tmp/duplicity/ file:///home/bancal/tmp/backup_storage
$ rm fooo
$ duplicity --no-encryption --file-to-restore fooo file:///home/bancal/tmp/backup_storage /home/bancal/tmp/duplicity/fooo
$ ls -l /home/bancal/tmp/fooo fooo
lrwxrwxrwx 1 bancal bancal 21 2012-02-10 14:36 fooo -> /home/bancal/tmp/fooo
-rwxrwxrwx 1 bancal bancal 0 2012-02-10 14:33 /home/bancal/tmp/fooo

# Note that original file's mod has changed to 777!!! (even if it is outside the scope of the backup!)

[Barni (butterfly-barni)]

Hi

I stumbled upon this issue recently and found this old bug report. I believe this is a security issue.

Are the developers still working on bug reports here at launchpad, or should we reopen this over at https://gitlab.com/duplicity/duplicity ?

[Kenneth Loafman (kenneth-loafman)]

0.6.17 is way past EOL.

Please upgrade to the current version of duplicity, 0.8.20. This will assure that any bugs fixed since your release are available and may fix your issue.

There are multiple options both stable and latest:
- Stable snap builds - “sudo snap install duplicity —classic"
- Latest snap builds - “sudo snap install duplicity —classic —edge"
- Stable pip3 builds - “sudo python3 -m pip install duplicity"
- Latest pip3 builds - “sudo python3 -m pip install --pre duplicity"
- Stable duplicity PPA - https://code.launchpad.net/~duplicity-team/+archive/ubuntu/duplicity-release-git
- Latest duplicity PPA - https://code.launchpad.net/~duplicity-team/+archive/ubuntu/duplicity-develop-git
- Stable tarball install - https://launchpad.net/duplicity/+download
- Source - https://gitlab.com/duplicity/duplicity

Note 1: UNINSTALL duplicity first if it was installed from a different source.. This is due to divergent install locations, especially between repository installs and the other forms.

Note 2: Launchpad PPAs contain builds for Bionic 18.04, Eoan 19.10, Focal 20.04, Hirsute 20.10 and Impish 21.04.

Note 3: Xenial 16.04 works with Snap and Pip installs, but cannot be built under Launchpad PPAs at the moment.

[Barni (butterfly-barni)]

We verified that this bug is still present on duplicity 0.8.20.

[Kenneth Loafman (kenneth-loafman)]

Marking this as incomplete since I cannot reproduce. Here's what I get. I modded the example to work universally. It's attached.

ken@dione:~/workspace/duplicity-git$ testing/manual/bug930151.sh
-rw-r--r-- 1 ken wheel 0 Oct 22 12:35 /tmp/foo
lrwxr-xr-x 1 ken wheel 8 Oct 22 12:35 foo -> /tmp/foo
Warning, found signatures but no corresponding backup files
Synchronizing remote metadata to local cache...
Last full backup date: none
No signatures found, switching to full backup.
--------------[ Backup Statistics ]--------------
StartTime 1634924117.97 (Fri Oct 22 12:35:17 2021)
EndTime 1634924117.97 (Fri Oct 22 12:35:17 2021)
ElapsedTime 0.00 (0.00 seconds)
SourceFiles 2
SourceFileSize 104 (104 bytes)
NewFiles 2
NewFileSize 104 (104 bytes)
DeletedFiles 0
ChangedFiles 0
ChangedFileSize 0 (0 bytes)
ChangedDeltaSize 0 (0 bytes)
DeltaEntries 2
RawDeltaSize 0 (0 bytes)
TotalDestinationSizeChange 125 (125 bytes)
Errors 0
-------------------------------------------------

Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Fri Oct 22 12:35:17 2021
-rwxr-xr-x 1 ken wheel 0 Oct 22 12:35 /tmp/foo
lrwxr-xr-x 1 ken wheel 8 Oct 22 12:35 foo -> /tmp/foo

[Barni (butterfly-barni)]

Your test shows the issue:

First /tmp/foo has 644 and after restoring the symlink the file has 755.

The only difference is that your symlink has 755 instead of 777 in Samuel and my test case.

The point is, after restoring the symlink the permissions of the symlink are copied to the symlinks target.

[Kenneth Loafman (kenneth-loafman)]

My bad. Not enough coffee. You are correct.

[Kenneth Loafman (kenneth-loafman)]

You found a weird one. Thanks!

Turns out it was modding both the perms and the modtime. Fixed.

[Barni (butterfly-barni)]

Thanks for the fix. The issue is solved with your latest change.

I looked at your commit and noticed a chown just above your changes. This seems to have the same issue. When you run the restore as root, duplicity will change the owner of the symlink's target too if they didn't match.

To reproduce add `chown -h www-data:www-data foo` to your script at line 12 and run the script as root. Replace www-data with a valid user on your system.

[Kenneth Loafman (kenneth-loafman)]

Fixed. Thanks!