Some user-permission changes to btrfs-progs #762
Conversation
For non-root usage, receive can't write compressed data and will get EPERM, but falling back to writing uncompressed data may work and allows receive as a normal user, which is safer. Signed-off-by: Sweet Tea Dorminy <[email protected]>
The user ioctl works in all cases, so don't limit subvolume list to root by using the root-only ioctl. Subvolume list itself still uses the root-only tree search ioctl, but this is a step toward making subvolume list user-capable. Signed-off-by: Sweet Tea Dorminy <[email protected]>
|
For data writes it's totally fine to fallback to non-privileged writes. But wouldn't things like snapshotting and UUID tree updates still requires root privilege? |
|
Snapshotting shouldn't require root? But uuid search, good point, I was running on a kernel with uuid search allowed for non-root. |
|
There are the unprivileged subvolume ioctls, I'm not sure if there are also helpers for that but this should be possible to implement by manual iteration. |
kdave
force-pushed
the
devel
branch
4 times, most recently
from
247e2d2
to
208150e
Compare
kdave
force-pushed
the
devel
branch
2 times, most recently
from
0bbf8b9
to
bcb887a
Compare
kdave
force-pushed
the
devel
branch
2 times, most recently
from
87a1129
to
e4d372e
Compare
|
I'm taking another look, the idea of using unprivileged ioctls makes sense but we can go further and use the library functions (receive code is old so the interface was not there). I'd apply the patches but the change in lookup_ino_path() to |
kdave
force-pushed
the
devel
branch
2 times, most recently
from
ca84db7
to
8e8c554
Compare
kdave
force-pushed
the
devel
branch
3 times, most recently
from
c94327d
to
2ce4219
Compare
kdave
force-pushed
the
devel
branch
4 times, most recently
from
082ce75
to
84c044d
Compare
kdave
force-pushed
the
devel
branch
2 times, most recently
from
f6d1943
to
5ff9f62
Compare
adam900710
force-pushed
the
devel
branch
2 times, most recently
from
b7cd74f
to
66f08f9
Compare
This makes it possible to use btrfs receive as a regular user, and gets part of the way to using btrfs subvolume list as a regular user (the main change there is pretty big so it's going in a different pull request).