Am Thu, 2 Feb 2017 10:52:26 +0000
schrieb Graham Cobb [off-list ref]:

On 02/02/17 00:02, Duncan wrote:

quoted

If it's a workaround, then many of the Linux procedures we as
admins and users use every day are equally workarounds.  Setting
007 perms on a dir that doesn't have anything immediately security
vulnerable in it, simply to keep other users from even potentially
seeing or being able to write to something N layers down the subdir
tree, is standard practice.  

No. There is no need to normally place a read-only snapshot below a
no-execute directory just to prevent write access to it. That is not
part of the admin's expectation.

Wrong. If you tend to not be in control of the permissions below a
mountpoint, you prevent access to it by restricting permissions on a
parent directory of the mountpoint. It's that easy and it always has
been. That is standard practice. While your backup is running, you have
no control of it - thus use this standard practice!

If you want to make selective or general access to the backups,
snapshot them to a different location later. You should really learn
how to work with scratch locations for a backup. The receiver is such a
scratch location and should be handled like it.

Scratch directories for backup locations are not a bug and not a
workaround. It's just how you should handle it and how it works. By
definition, the target directory cannot be read-only while the backup
is running - so by definition you need other means to protect it.

That in turn defines all your current locations for snapshot as scratch
locations. Put your final snapshots somewhere else if you want your
users access these after successful finishing a backup. You never want
people to access in-transit or partial backups. In-transit and partial
always goes to the scratch directory. Only then, after success of the
backup, a backup should be made available in a final directory.

Maybe your design of your backup is wrong, and not how btrfs handles
that? Using scratch locations is a design you should really really
always use for backups. Every sophisticated admin would agree that this
should be best practice.


-- 
Regards,
Kai

Replies to list-only preferred.