Decide if it makes any sense to backup proc
Issue by ericzolf
Sunday Jul 21, 2019 at 08:25 GMT
Originally opened as https://github.com/ericzolf/rdiff-backup/issues/35
proc is generated on the fly so it might not make sense to backup it. Some points to consider:
- SELinux keeps a normal user from accessing /proc, perhaps it works better with root?
- Would need at least to fail graciously?
- How to detect a proc filesystem (might be somewhere else than /proc)?
- Do we allow knowledgeable users to backup proc?
- Need to adapt finaltest to approach (3 tests are being skipped for now)
In the meantime, recommendation is to exclude /proc from backup.
Comment by ericzolf
Thursday Jul 25, 2019 at 17:50 GMT
It's not a regression, rdiff-backup 1.2.8 (Fedora) has exactly the same kind of issue when trying to backup /proc as normal user or even as root (many SELinux errors).
So this won't be fixed as part of the migration to Python 3.
If something is blocked by SELinux, AppArmor or some other Linux security module, being root does not bypass it.
I can't think of any sensible use case shy somebody would like to backup /proc. I'd suggest that rdiff-backup would just skip or fail gracefully is somebody accidentally tries to backup /proc, /sys, /dev or /run.
I don't think we should build in things like this - there are plenty of include and exclude options already for this sort of thing. /proc isn't relevant everywhere, and maybe some weird docker or LXC thing might mean you can or maybe want to backup something that looks like /proc and isn't.
While I agree that it is better not to build such exclusions into rdiff-backup, any such exclusions should be based on filesystem type, not on the mountpoint. /proc is type proc, /sys is type sysfs, /dev looks to be type devtmpfs, etc.
Actually, decision was taken: no special handling (while I agree that the filesystem type is tempting, someone will always find an exception where it might make sense, so let's leave it to the user to decide what to exclude or not).