document how to create a full backup without running restic as root #1483
Conversation
|
|
||
| .. code-block:: console | ||
|
|
||
| root@a3e580b6369d:/# useradd -m restic |
There was a problem hiding this comment.
If sudo is always used, would it make sense to restrict the login shell (-s /bin/false), too?
There was a problem hiding this comment.
It would not be a bad idea to do that. But personally, I find it very convenient that I can run a shell as user restic and use it examine or restore backups.
There are a lot of things that you could do to harden or optimize the setup. But I think that is out of the scope of this chapter.
doc/080_examples.rst
Outdated
|
|
||
| .. code-block:: console | ||
|
|
||
| root@a3e580b6369d:/# sudo -u restic -H -s |
There was a problem hiding this comment.
There may be a good reason for it which I cannot see, but why two commands instead of, e.g. sudo -u restic ~restic/bin/restic -r /tmp backup /
Likewise, what is the rationale for -x? I'd assume backing up the whole system may require to access multiple file systems, may it not? In case you really want to have -x it needs to be after backup as it is not a global flag.
Should --exclude /tmp as the repository be added here? Or how about adding --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/lost+found"}
There was a problem hiding this comment.
Yes, we could easily put sudo and the call to restic a single command.
The intention for the -x was to prevent a clueless reader from backing up his /proc or /sys which might never actually terminate. But you are right, a proper generic exclude list, that works for most people, is a better fit. And -x might exclude /home, which is quite commonly on a separate filesystem.
Codecov Report
@@ Coverage Diff @@
## master #1483 +/- ##
==========================================
- Coverage 51.55% 46.29% -5.26%
==========================================
Files 138 138
Lines 11080 11080
==========================================
- Hits 5712 5130 -582
- Misses 4503 5139 +636
+ Partials 865 811 -54
Continue to review full report at Codecov.
|
|
|
||
| .. code-block:: console | ||
|
|
||
| root@a3e580b6369d:/# setcap cap_dac_read_search=+ep ~restic/bin/restic |
There was a problem hiding this comment.
Although I agree, that restic ideally shouldn't be run as root, assigning cap_dac_read_search to the binary directly is dangerous as this would allow now anyone able to execute restic to also ready any system file.
I'd rather handle this by letting systemd control all those aspects.
My WIP service instance unit for restic: /etc/systemd/system/restic@.service
[Unit]
Description=Backup %I using 'restic'
ConditionFileNotEmpty=/etc/restic/%i/restic.env
ConditionPathExists=/etc/restic/%i/backup.exclude
[Service]
ExecStart=/usr/bin/restic backup --cache-dir=/var/cache/restic/%i --one-file-system --exclude-file=/etc/restic/%i/backup.exclude --exclude=/var/cache/* --exclude=/tmp/* --exclude=/var/tmp/* --exclude=/home/*/.cache/* --exclude=/run/* --quiet /
Type=oneshot
EnvironmentFile=/etc/restic/%i/restic.env
DynamicUser=yes
PrivateDevices=yes
CacheDirectory=restic/%i
CacheDirectoryMode=0700
ConfigurationDirectory=restic/%i
ConfigurationDirectoryMode=0700
#SystemCallFilter=@basic-io @file-system @network-io @io-event @ipc @cpu-emulation
#SystemCallErrorNumber=EPERM
AmbientCapabilities=CAP_DAC_READ_SEARCH
# TODO
# fix SystemCallFilter= usage, which currently fails, although the required tls syscall should be included in @default:
# -- cannot set up thread-local storage: cannot set %fs base address for thread-local storage
# - does restic support sd_notify()? if not, create an RFC or PR
# - ensure systemd's ProtectSystem= (+ related options) is utilized to the fullest
# - set low io class
There was a problem hiding this comment.
Although I agree, that restic ideally shouldn't be run as root, assigning cap_dac_read_search to the binary directly is dangerous as this would allow now anyone able to execute restic to also ready any system file.
Indeed, and that's why the permissions are set like this:
root@a3e580b6369d:/# chown root:restic ~restic/bin/restic
root@a3e580b6369d:/# chmod 750 ~restic/bin/restic
Did you see that?
fd0
added
state: need feedback
|
ping @dstosberg, are you still interested in continuing the work here, or should someone else take over? |
document how to create a full backup without running restic as root
What is the purpose of this change? What does it change?
Add an example section to the documentation that explains how one can use restic to create a full backup without having to run it as root.
Was the change discussed in an issue or in the forum before?
The idea occurred in discussing issue #1473.
Checklist
CHANGELOG.mdfile that describe the changes for our usersgofmton the code in all commits