Add support for non-root users

[mickours]

First, Snazzer is pretty exactly what I was looking for to backup my system, so thanks a lot for your great work :)

When I use snazzer to snapshot a subvolume in my home I would like to be able to explore it without being the root permission. But, the .snapshotz file have the following file permission: drwx------ 1 root root.

Is there a good reason for this? I think creating root folder in the user home is not a good practice don't you?

[csirac2]

Hi @mickours! Thanks for your contribution. Snazzer really needs some love, as you can see :)

There is a variable at the top of the snazzer script, SNAZZER_SNAPSHOTZ_PERMS which you can hack with a different set of bits if you so wish.

However, generally I didn't think of non-system owners (i.e. non-root) running and exploring their own snapshots: I suppose at the time, I thought this would introduce security considerations I didn't have time to think through, so the root-only stuff is a result of me trying to keep things simple.

I will re-title your issue as "Improve support for non-root users", it's a great idea.

If you'd like to contribute to the development, please do - if you propose some documentation change (as a proposal on how you want it to work), I can write the code, or vice-versa :)

[florianjacob]

This is actually possible without changing the script source, I've always run snazzer that way. I guess I have to investigate what I actually did to make this work, but I cant remember anything specifically, (and did not document my setup because I thought I was only fiddling around and will document it later when I found a good setup. 😆)

I think I manually changed the owner of .snapshotz to my user and group (and used chmod g+s, but that should not be relevant as it's only the group), but other that that?… But maybe that was enough?

But definitely all my newly created snapshotz in /home//.snapshotz/2017-… are owned by and are therefore accessible without root permissions.

[florianjacob]

@mickours can you tell us more about your subvolume layout and home directory permissions? I just tested to change .snapshotz back to be owned by root:root but the newly-generated snapshots are still : and mimic my home directory's permissions. In theory, the only thing you'd need to change is to chown .snapshotz to the respective user, and you're ready to go, snazzer won't touch the owner and group of the .snapshotz file again, and the snapshot folders inside .snapshotz should have the same permissions as the source subvolume.

[mickours]

Thanks for your answers,

I have a subvolume on my /home which I do not want to be accesible for everyone, and a special one for my pictures in ~/Images/My_Photos/.

In fact only the .snapshotz was in root but the internal snapshots gets the right permissions: drwxr-xr-x 1 mercierm mercierm

So, as you suggest I changed the permission with:

sudo chown $USER ~/Images/My_Photos/.snapshotz

And that's it! It works like I want now.

Then I tried without changing the configuration with an other test subvolume in my home and I have the same behavior: access denied

So, I think the snapshots should be accessible by default to the user who made it, like: own by root but in the user group with 750 permission. Sounds good?

[florianjacob]

I created https://github.com/csirac2/snazzer/tree/non-root-user-support to implement the discussion results. As a baseline, we could copy owner and group from the source subvolume and still use 0700 as permissions - then root and the owner of the source subvolume have full access, but the group and others don't. A user could modify group access if he needs that as well. This would change nothing in the case of a root owner, and make history accessible to non-root owners. The snapshots themselves could now be deleted by the owner if the mount option user_subvol_rm_allowed is specified. Use cases I can think of as affected by this are a) home directories and b) service directories, e.g. /var/www for web servers, or stuff like samba shares. Note that the files inside the snapshots are always read-only.

Found an easy way to do this: https://github.com/csirac2/snazzer/commit/621a517589d7fd010d78bd9b63e0a6df7fddf50c

About the permissions:

• We could reduce the permissions to 0400 or 0440, which would deny the user to delete subvolumes even with user_subvol_rm_allowed. (root can still do this, regardless whether root is owner or not.) This would prevent eg. a compromised web server from deleting history, but hinder a user from cleaning up snapshots easily when they're e.g. using up too much space. (Of course, local history doesn't replace a backup).

• We could copy the permissions from the source, probably raising them by doing that. Additionally to what's discussed above, this will most-likely introduce history read privileges and maybe history write privileges for the group. Also probably history read privileges for other, as many system are configured with a 0022 umask.

This boils down to two key questions:

1. Should owner and/or group and/or others be allowed to read history, if they can read source?
2. Should owner and/or group and/or others be allowed to delete history, if they can delete the source?

My opinion: 1. is of low impact but help alot in usability. The main impact would be a case where a user deposits confidential information in the source by accident, and forgets to delete it from history. I'm not sure about 2. No write would by default prevent accidental history deletion by users and malicious history deletion by corrupted services or binaries the user executes, and the user could selectively add this where they want. On the other hand, this prevents a user from being able to clean up his history by default, and you can rightfully say that .snapshotz is no backup anyway, but only a separate location created via snazzer-receive is.

What's yours? 😄

[csirac2]

Backups are a rich source of infoleaks in security-sensitive environments - I'm very nervous about opening them up: if you've ever been asked to purge old backups that might contain sensitive information accidentally saved to the wrong place, you'll know what I mean.

I think it's fair to make it so that subvolume owners can create/read old snapshots, but nobody else (other than root obviously). So I think your proposed commit is a good solution.

I'm less worried about accidental deletes: that's what snazzer-receive is for.

If that's not enough, is there a way we could make the error message more helpful? I'd rather fail with a helpful error message than do anything more liberal than your proposal.

[mickours]

For 1, I think we all agreed that:

subvolume owners can create/read old snapshots, but nobody else

For 2, I think owner should be able to delete history by default simply because if this owner do not have sudo access he will never be able to delete his history. It is also important for the infoleaks issue I think.

[csirac2]

Great, I'd be happy to see https://github.com/csirac2/snazzer/tree/non-root-user-support go ahead. I've been meaning to rework the way we do $SUDO in the codebase, perhaps I'll try to find time to take a look at what else assumes root/sudo this weekend. Feel free to create a testcase.

[florianjacob]

PR ready for review at #56. 😄

[florianjacob]

Backups are a rich source of infoleaks in security-sensitive environments - I'm very nervous about opening them up: if you've ever been asked to purge old backups that might contain sensitive information accidentally saved to the wrong place, you'll know what I mean.

@csirac2 Thanks alot for that insight – actually I have not been in that situation so far and therefore have not thought of this, but I can imagine now. 😆