Hello, > $ /sbin/btrfs subvol create /tmp/test > Create subvolume '/tmp/test' > $ /sbin/btrfs subvol delete /tmp/test > Delete subvolume '/tmp/test' > ERROR: cannot delete '/tmp/test' - Operation not permitted
That is a little strange anyway. Looking into codes, i found For sub-volume creation, we don't check CAP_SYS_ADMIN while For sub-voule deletion, we do check CAP_SYS_ADMIN, however, we still have a mount option "user_rm_subvol_allowed" to delete a sub-volume by regular users! IMO, this is a little confusing and arguable. i see there are some discussion by googling, for example: http://unix.stackexchange.com/questions/88932/why-cant-a-regular-user-delete-a-btrfs-subvolume Thanks, Wang > > The above is when running Debian kernel 3.12 based on Linux upstream 3.12.8. > I believe that the BTRFS kernel code should do a capabilities check for > CAP_SYS_ADMIN (which is used for mount/umount among many other things) before > creating a snapshot. Currently it appears that the only access control is > write access to the parent directory. > > There is some possibility of debate about the access control needed for > creating a subvol. I want to use capabilities set by SE Linux policy to > prevent unwanted actions by hostile root processes and I think that such use > of capabilities (which is used by more than just SE Linux) should be > supported. I don't think that there is any downside to such checks. > > In any case allowing a subvol to be created but not deleted with the same > level of access is obviously a bug. > > -- > My Main Blog http://etbe.coker.com.au/ > My Documents Blog http://doc.coker.com.au/ > > -- > 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 -- 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
