- 
                Notifications
    You must be signed in to change notification settings 
- Fork 263
Some user-permission changes to btrfs-progs #762
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: devel
Are you sure you want to change the base?
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. | 
247e2d2    to
    208150e      
    Compare
  
    0bbf8b9    to
    bcb887a      
    Compare
  
    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  | 
ca84db7    to
    8e8c554      
    Compare
  
    c94327d    to
    2ce4219      
    Compare
  
    082ce75    to
    84c044d      
    Compare
  
    ef43ce6    to
    3eff852      
    Compare
  
    dafafca    to
    5d47f58      
    Compare
  
    bb6a159    to
    0fb0189      
    Compare
  
    0ad9c81    to
    9c1d53d      
    Compare
  
    5d51853    to
    6ea7070      
    Compare
  
    9551363    to
    94c16d5      
    Compare
  
    d82be5c    to
    25f665e      
    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).