Merge confidential file excludes into single -c option

[lucianposton]

Added -u flag to optionally exclude .bash_history.

Merged .bash_history and connman lists into single -c option.

Also added /root/.bash_history to -c.

[TheChymera]

I don't think this is a good idea; including potentially confidential user data by default opens the system to all sorts of privacy mishaps. I also agree that parameterizing it inversely, i.e. “don't exclude .bash_history” can be confusing. Probably the best solution would be to create a master parameter to exclude user data, and if someone wants more fine-grained control, he can use the --exclude options directly.

[lucianposton]

I don't think this is a good idea; including potentially confidential user data by default opens the system to all sorts of privacy mishaps.

I get where you're coming from, but .bash_history seems like an odd place to start if excluding sensitive info is a goal. While bash history is indeed confidential, it pales in comparison to what's already being included from $HOME, not to mention the confidential /etc info most people would expect to be included when using a stage4 as a backup.

Consider ssh host keys in /etc, ssh user keys in HOME, gpg keyring in HOME, mail in /var, mail in ~/.maildir, vms with their own private data, luks backups, plain text passwords in /etc/wpa_supplicant, pw hashes in /etc/shadow (crackable in minutes, or seconds if using md5), firefox and chrome browser history, history of other commonly used shells like zsh. It's a large list. I'd be happy if the only thing leaked from my backup were a .bash_history file, but I'm also unusually diligent about keeping credentials out of my shell history. :)

I suspect the most common use case for making a stage4 is system backup. In that case, you'd generally want to include many of these sensitive files by default in order to restore to a similar environment (I suspect this is more true of info in /etc than HOME data though).

As you suggested, an option that (attempts to) exclude user data from HOME and host-specific keys/credentials from /etc would be a nice option for the use case where you want to setup another gentoo machine similar to, but different from, an existing machine i.e. a different host.

For this PR, do you want me to update the wording of the -u option so that its intended purpose is to exclude user-specific and host-specific data?

[TheChymera]

I get where you're coming from, but .bash_history seems like an odd place to start if excluding sensitive info is a goal.

I totally agree, we're not handling this properly right now either, it's just that expanding the selection of excluded files/directories individually (when this can already be done with) --exclude is probably not the best way to move forward.

I think perhaps the best option would be a -c parameter to supersede the current connman parameter, and globally exclude all potentially confidential data. This might be a bit more involved, especially with regard to /etc/shadow, which should allow password-less root login (another prominent use case in addition to backup, is creating images for collaborators to rapidly start working on projects, which is what my lab uses this script for).

[TheChymera]

Thanks for doing this! Do you plan to add more things, or shall we leave it like this for now?

[lucianposton]

Was thinking to add /var/log/* into it. Thoughts?

[lucianposton]

Actually, go ahead and plan to merge it as is for now. Handling /var/log/* the way I'd prefer would be more work/brainstorming than I first realized.

That said, I'd prefer if https://github.com/TheChymera/mkstage4/pull/34 be merged first, if ya don't mind. If you end up merging that, I'll need to adjusts some test cases as part of this PR.

[TheChymera]

Ok, Let's wait on that first

[lucianposton]

Updated tests in this PR and they now pass, so ready to merge this.