On 2017-03-29 01:38, Duncan wrote:
Austin S. Hemmelgarn posted on Tue, 28 Mar 2017 07:44:56 -0400 as
excerpted:
On 2017-03-27 21:49, Qu Wenruo wrote:
The problem is, how should we treat subvolume.
Btrfs subvolume sits in the middle of directory and (logical) volume
used in traditional stacked solution.
While we allow normal user to create/delete/modify dir as long as they
follow access control, we require privilege to create/delete/modify
volumes.
No, we require privilege to do certain modifications or delete
subvolumes.
Regular users can create subvolumes with no privileges whatsoever, and
most basic directory operations (rename, chown, chmod, etc) work just
fine within normal UNIX DAC permissions. Unless you're running some
specially patched kernel or some LSM (SELinux possibly) that somehow
restricts access to the ioctl, you can always create subvolumes.
(I believe) You misread what QW was trying to say. Note the word "volume"
as opposed to subvolume. Like most regulars here, Qu's too deep into
btrfs to make that sort of mistake, so he wasn't talking about subvolumes.
Ah, you're right, I need to quit reading so fast all the time :)
Rather, he's placing btrfs subvolumes in the middle between directories
and (generic/logical) volumes as normally used, and saying that for
(generic) directories normal users can create/modify/delete without
special privilege (beyond write in the parent), for (generic) volumes
special privileges are necessary to create/modify/delete, and btrfs
subvolumes fall in between, so there's a real decision to be made in
terms of privileges required, do they follow directories and require
nothing special or volumes and require special privs?
Meanwhile, my own position as I've argued is that regardless of the
theoretical debate, as long as we have the very real practical issue of
hard scaling issues for subvolumes/snapshots, there's an equally real
security issue in allowing unrestricted snapshot and to a lessor extent
normal subvolume creation.
There is a bigger issue though in that subvolumes are a resource a
regular user can create but not destroy and there is no way to limit the
number a user can create. This is never a good situation to be in, but
it appears to have arisen because there are no proper privilege checks
on subvolume deletion, just the 'are you EUID 0?' thing. The ioctl
should require some proof that you could delete the subvolume if it were
a directory, then we could get rid of the whole 'user_subvol_rm_allowed'
thing and move on a bit more sensibly.
So while we might /like/ to make subvolumes more like directories and
require no special privs, until the snapshot scaling and thus security
issue is fixed or at least greatly reduced, as a purely practical
security matter, we really need to restrict snapshot creation to
privileged users.
OTOH, it's worth pointing out that snapshots aren't unique in this
regard, reflinked files have exactly the /same/ scaling issues except
their one-by-one while snapshots tend to be a whole bunch of reflinked
files at once.
Snapshots and reflinks have scaling issues on every filesystem I've seen
that supports them internally that isn't inherently log structured. The
scaling issue is far worse on BTRFS than most others, but it's by no
means unique to BTRFS.
Which means the question must then be asked, if we choose the privileged
route for snapshots/subvolumes due to the reflinking security issues, why
aren't we making all reflinking ops privileged ops, or should we? If we
did, cp --reflink=always, among other things, would obviously fail as a
normal user.
Normal users should be able to use reflinks. That is the expectation
set forth by BTRFS already, as well as other filesystems which support
reflinks.
So I guess it's a rather harder question than I considered at first.
Maybe we /should/ just treat subvolumes as directories in privileges
terms as well. In that case, however, we really need to have the same
default for subvolume deletion as creation.
--
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
