|Summary:||Ensure correct permissions when trying to create a share of a folder in the user's homedir|
|Product:||kdenetwork-filesharing||Reporter:||Nate Graham <nate>|
|Component:||general||Assignee:||Nate Graham <nate>|
|Latest Commit:||https://invent.kde.org/network/kdenetwork-filesharing/commit/869129c0c8e055d324504e24e38e236bd7fc1bc0||Version Fixed In:||22.08|
Description Nate Graham 2019-05-27 00:03:46 UTC
In order to create Samba shares in the user's home directory, the whole home folder needs to have execute permissions for "other" (see https://wiki.manjaro.org/index.php?title=Using_Samba_in_your_File_Manager#Sharing_In_The_Home_Directory) So when the user is trying to share a folder in their homedir, we should take care of this automatically, or else it will just fail with no indication of why. In addition, we should display a warning that sharing a folder in your homedir can potentially open you up to security issues.
Comment 1 Harald Sitter 2020-03-17 15:49:18 UTC
This is a bit more involved than what is described: To traverse any directory the user (that is the user logged into the samba share) needs to have +x on all parenting directories of the folder they are trying to navigate. That isn't specific to home, nor is it specifically about the home directory. Namely whenever a share is created we should actually walk up the dir tree and +x on all directories. And that +x is also a bit tricky because either you set all +x or you figure out which +x needs setting (in POSIX ACL or mode, as available and applicable). I am not sure what the security implications of +x exactly are, but forcing +x on everything seems a bit questionable. Windows fundamentally has the same problem btw, and they've made a share wizard to deal with this. Because in the end this is just one example of the eternal conflict ShareACL != FileSystemACL. I.e. just because you give a user access on a share level doesn't mean they have access on a file system level. So with their wizard you just say userX should have RW access and userY should have R access. The wizard then bends both types of ACLs into place all the way up the directory tree so they meet the expected outcome. I feel like that may be where we should go too. Advanced users on the other hand could totally avoid the wizard and instead fiddle with the ACLs and have constructs like fullcontrol for everyone on a share level but then restrict effective access via the file system (that is actually how windows wizard shares work I think; they share the top most directory and then adjust NTFS permissions below that).
Comment 2 Harald Sitter 2022-03-24 12:10:18 UTC
Git commit 869129c0c8e055d324504e24e38e236bd7fc1bc0 by Harald Sitter, on behalf of Slava Aseev. Committed on 24/03/2022 at 12:10. Pushed by sitter into branch 'master'. Add shared folder permissions helper The helper provides ability to resolve shared folder permissions on-demand. If shared folder's permissions (or its paths parts) are insufficient at some point for some user's ACE the helper suggests to change permissions and performs required changes after user's confirmation. Implementation of permissions resolutions tightly based on: https://invent.kde.org/network/kdenetwork-filesharing/-/merge_requests/16 M +1 -0 samba/filepropertiesplugin/CMakeLists.txt M +9 -0 samba/filepropertiesplugin/model.cpp M +5 -0 samba/filepropertiesplugin/model.h A +231 -0 samba/filepropertiesplugin/permissionshelper.cpp [License: GPL(3+eV) GPL(v3.0) GPL(v2.0)] A +78 -0 samba/filepropertiesplugin/permissionshelper.h [License: GPL(3+eV) GPL(v3.0) GPL(v2.0)] M +28 -0 samba/filepropertiesplugin/qml/ACLPage.qml A +130 -0 samba/filepropertiesplugin/qml/ChangePermissionsPage.qml [License: GPL(3+eV) GPL(v3.0) GPL(v2.0)] M +2 -0 samba/filepropertiesplugin/qml/qml.qrc M +10 -0 samba/filepropertiesplugin/sambausershareplugin.cpp M +5 -0 samba/filepropertiesplugin/sambausershareplugin.h https://invent.kde.org/network/kdenetwork-filesharing/commit/869129c0c8e055d324504e24e38e236bd7fc1bc0