On 2017-02-02 05:52, Graham Cobb wrote:
On 02/02/17 00:02, Duncan wrote:
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.
That depends on the admin. I for example would absolutely expect that
to be needed _while the snapshot is being created_ if the operation
isn't being done by the kernel.
Which is my point. This is no different than standard security practice,
that an admin should be familiar with and using without even having to
think about it. Btrfs is simply making the same assumptions that
everyone else does, that an admin knows what they are doing and sets the
upstream permissions with that in mind. If they don't, how is that
btrfs' fault?
Because btrfs intends the receive snapshot to be read-only. That is the
expectation of the sysadmin. It is an important and useful feature which
makes send/receive very useful for creating
user-readable-but-not-modifiable backups (without it, send/receive are
useful for many things but less useful for creating backups). That
feature has a bug.
If that's your use case, then from a consistency perspective, you should
be receiving into a location the user can't read and then moving the
subvolume into a user readable location once receive is done anyway.
Otherwise, they may see a partial snapshot, and think something has been
deleted that really hasn't. This is a pretty basic method of ensuring
consistency that's used literally all over the place on UNIX systems to
atomically replace or update data sets. Doing so also cleanly avoids
needing to manipulate permissions on the directory the snapshots are in
to prevent users from modifying the snapshots being received.
Just because you don't personally use the feature, doesn't mean it isn't
a bug! Many of us do rely on that feature.
Even though it is security-related, I agree it isn't the highest
priority btrfs bug. It can probably wait until receive is being worked
on for other reasons. But if it isn't going to be fixed any time soon,
it should be documented in the Wiki and the man page, with the suggested
workround for anyone who needs to make sure the receive won't be
tampered with.
I agree that it should be documented. I don't agree that a specific
workaround needs to be stated, as whether or not any particular
workaround is needed is entirely dependent on the use case. For
example, if your users can only access the received snapshots over a
networked filesystem, there's a much simpler option of just exporting
the directories the snapshots are received into as read-only. All that
needs to be stated is that the way to prevent this is to make sure users
can't write to the snapshots while they're being received.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
