Mounting encfs under /tmp might be a bad idea.

[ivh]

I used backintime 1.0.34 from Debian/jessie with a local (usb-disk) encrypted volume. It turns out the gnome-settings-daemon does housekeeping in /tmp when you tell it to, deleting all files older than X. Backintime mounts its encrypted volumes at /tmp/backintime/foo/mnt/XXXXXXX/mountpoint which resulted in the housekeeping to delete files in it (and through backed-up symlinks also in $HOME!). This wrecked my files and the backup, so I had to recover from secondary.

I don't want to start the blame-game between gnome and backintime, but ask whether /tmp is a good choice of mount point at all.

[Germar (germar)]

Urgs! That's really bad! Didn't know of such a 'feature'. I'm already downloading jessie image to confirm this in a VM.

We choosed /tmp because it get cleaned up during restart (or when speaking correctly, it is a ram disk which doesn't survive a reboot). So if the mountpoint would get messed up for what ever reason it would work again after next reboot. Also we need to have a path which is writeable for every user.

[Germar (germar)]

I'm not sure what's the best way to fix this. So I would like to start a discussion about this.

We need to have a place which is writeable for all users and which can easily be excluded to prevent backing up other users snapshots. So it should be one 'central' folder for all users.

One approach would be to use $XDG_RUNTIME_DIR. But this isn't set during cronjobs. So we would need to make some crude workarounds to find out the path.

I think it would be better to create an init script which will create /run/backintime and chmod 1777 this folder to make it writeable for all. BackInTime would use /run/backintime in the same way as /tmp/backintime before. It would be necessary to call this script after installation.

[Dan (danleweb)]

To summarize:

 * It's better to have a folder that is writable by all users. But for systems where there is only one user (like most personal usage) I think this is not a "must". On systems with many uses it's nice to have. I think we can have a look if this can have some security issues (it it does have we must ask us again if we really need a folder writable by all users).

 * It's a good ideea to have it as tmpfs. This way a reboot will clear everything ... just in case. If not we can always make a workaround.

* $XDG_RUNTIME_DIR it user related. So it we need a "global" place I don't thik this is the right place. But if we need an env variable we can pass it to crontab job.

I think that we should to the following actions in this order:

 1. Find if we really need a folder writable by all user ? What are the pro / con ? What can be the disavantages of using a "per user" folder ?

 2. We should implement a flexible approach. To find the right folder by searching in this order
     * Check a global property from the settings
     * Checking a env variable (ex: BIT_TMP_FOLDER)
     * Using an evn variable ($TMP, $TEMP, $XDG_RUNTIME_DIR)
     * Use /tmp

What do you thing ?

[Germar (germar)]

With $XDG_RUNTIME_DIR we could force exclude /run (IMHO there is no need to backup run at all). So we don't need a 'global' place

But I forgot to mention that $XDG_RUNTIME_DIR ('/run/user/<UID>') does not exist if the user is not logged in (it will be created by pam-xdg-support module during login). So even if we pass the env var to our cronjob it won't work.

1. We could also make an init script which will create /run/backintime/<USER> for all users registered on the system and make them read/writeable just by them selfs.

Pros for a global writeable folder:
- easy to force exclude to prevent backing up other users snapshots
- no root permissions necessary

Cons:
- someone else could 'occupy' the mountpoint and get in touch with users data. I don't know how this would work but I'm sure it would be possible.

2. A 'flexible' approach would make it harder to exclude. E.g. if user A would set BIT_TMP_FOLDER=/foo/bar BIT running as root wouldn't know of this and backup users A snapshots.

3. An other approach might be to place the mountpoint in '~/.local/share/backintime/mnt'. Force exclude '.local/share/backintime/mnt/' should than match all users mountpoints. We only need to make sure to clean it up propperly.

[Dan (danleweb)]

Since there is no big issue to have a mount point folder "per user" then "~/.local/share/backintime/mnt" sounds perfect.

We can also add some tmpfs "clean-like": in "~/.local/share/backintime/mnt/last_uptime" file we can put the output of "uptime -s" command (update since). If this file exists and the content is different from a new run of "uptime -s" then we can clean all the content.

[Germar (germar)]

I'm a bit scared for adding such a clean-up routine. If the uptime compare fails for what ever reason and there is already a mountpoint in use it would again delete all backup and original data.
Till now I have not heard about corrupted mountpoints. So I'd rather like keep this a manual task.