Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question about restore behavior in Linux #561

Closed
Animedium opened this issue Aug 3, 2016 · 3 comments
Closed

Question about restore behavior in Linux #561

Animedium opened this issue Aug 3, 2016 · 3 comments
Labels
state: need feedback waiting for feedback, e.g. from the submitter

Comments

@Animedium
Copy link

Animedium commented Aug 3, 2016

Hi,

I was testing backup and restore with different permission options to file and I found restore option not consistent with Linux behavior.

So case is that 'User B' is owner of the file and 'User A' is making backup and restore with restic.
File have permissions set to 666 so 'User A' can backup this file with no problem.

Problems start with restore. As Linux user 'User A' can do various operations on that file and he can even remove it.
But during restore file cannot be replaced as long as user that make restore is not owner of the file.

Here is table with tests results

- -w- --- ---   User A : User A     will be restored
- --- -w- ---   User A : User A     will not be restored
- --- --- -w-   User A : User A     will not be restored
- -w- --- ---   User A : User B     will be restored
- -w- -w- -w-   User B : User A     will not be restored ?
- -w- -w- -w-   User B : User B     will not be restored ?

I would like to ask if this was designed that way or it should not work like that?

@fd0
Copy link
Member

fd0 commented Aug 3, 2016

Hi, thanks for opening an issue. I'm not sure I understood you correctly: You're testing restoring of file modes when the owner of the file is a different user than the one executing the backup, is that correct?

Could you please write up a few commands that show this behavior?

@fd0 fd0 added the state: need feedback waiting for feedback, e.g. from the submitter label Aug 3, 2016
@Animedium
Copy link
Author

Animedium commented Aug 3, 2016

So we have file file "test01.txt" that is owned by "ansible" user on which we perform tests.

ll | grep test01.txt

-rw-rw-rw- 1 ansible ansible   69 sie  3 13:27 test01.txt

First backup, no error here.

restic -r /temp/Restic/Repo backup /temp/Restic/Data/Files01/Dir01/test01.txt

enter password for repository: 
using parent snapshot ab2c7788
scan [/temp/Restic/Data/Files01/Dir01/test01.txt]
scanned 0 directories, 1 files in 0:00
[0:00] 100.00%  0B/s  69B / 69B  0 / 1 items  0 errors  ETA 0:00 
duration: 0:00, 0.00MiB/s
snapshot e1a1c87c saved

Then few commands to get file with required properties. Change owner.

sudo chown testuser:testuser test01.txt
ls -al | grep test01.txt

-rw-rw-rw- 1 testuser testuser   69 sie  3 13:22 test01.txt

Then restore. Here is error. Operation not permitted. File was not changed at all during operation.

restic -r /temp/Restic/Repo restore latest -t /temp/Restic/Data/Files01/Dir01 --path /temp/Restic/Data/Files01/Dir01/test01.txt

enter password for repository: 
restoring <Snapshot e1a1c87c of [/temp/Restic/Data/Files01/Dir01/test01.txt] at 2016-08-03 13:17:39.230116178 +0200 CEST> to /temp/Restic/Data/Files01/Dir01
error for /temp/Restic/Data/Files01/Dir01/test01.txt: create node: Lchown: lchown /temp/Restic/Data/Files01/Dir01/test01.txt: operation not permitted

Still as a "ansible" user I can remove file "test01.txt" and then restore it.

ls -al | grep test01.txt

-rw-rw-rw- 1 ansible ansible   69 sie  3 13:22 test01.txt

@fd0
Copy link
Member

fd0 commented May 14, 2017

The restore command at the moment does not alter existing files, especially it does not delete existing files. This is a safety feature. I'm going to close this issue for now, feel free to add further comments. Thanks!

@fd0 fd0 closed this as completed May 14, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
state: need feedback waiting for feedback, e.g. from the submitter
Projects
None yet
Development

No branches or pull requests

2 participants