I know permissions and privileges how-tos can be found anywhere by googling, and trust me, I've done it and thoroughly read every bit of information I could find on the subject. Either I'm not clever enough to resolve the issue (could very well be the case here) or there is no way to achieve what I want to do in the context I am setting.
In any case any feedback would be greatly appreciated.
Scenario
Users & Groups
- user1:group1 - here user1 belongs to his own group group1 by default (i.e - john:john)
- user2:group2 - here user2 belongs to his own group group2 by default (i.e - jane:jane)
- group3 - here group3 is completely independent (i.e sftp)
- user1 & user2 - also belong to group3
Files & Folders
- I have created an sftp jail for both users (chroot sftp using ssh with stanzas that match group1 for user1 & group2 for user2) in /path/to/chroot
- I have created 2 folders in /path/to/chroot - "private" and "public"
- I have created 2 folders in /path/to/chroot/public - "downloads" and "uploads"
What I want to achieve
"private" folder
- user1 should
- have full access (read/write/execute) to "private" folder, subfolders and files.
- not be allowed to delete the "private" folder itself but be allowed to do anything inside it
- user2 should
- have no access at all to this folder/subfloders and files
"public" folder
- user1 should
- not be allowed to delete the "public" folder but be allowed to browse it.
- not be allowed to write inside "public" folder
- user2 should
- not be allowed to delete the "public" folder but be allowed to browse it.
- not be allowed to write inside "public" folder
"public/downloads" folder
- user1 should
- have full access (read/write/execute) to "public/downloads" folder, subfolders and files.
- not be allowed to delete the "public/downloads" folder itself but be allowed to do anything inside it
- user2 should
- have read-only access to files and folders inside "public/downloads"
- not be allowed to delete the "public/downloads" folder
"public/uploads" folder
- user1 should
- have full access (read/write/execute) to "public/downloads" folder, subfolders and files.
- not be allowed to delete the "public/uploads" folder itself but be allowed to do anything inside it
- user2 should
- be allowed to add new files/folders in "public/downloads"
- be allowed to delete/edit files he has uploaded in "public/downloads"
- not be allowed to read/download/execute files that do not belong to him in "public/downloads"
- not be allowed to edit/delete files that do not belong to him in "public/downloads"
- not be allowed to delete the "public/downloads" folder
What I've accomplished already
- chroot (/path/to/chroot)
- private (user1:group1 0770)
- backups
- personal
- other
- public (root:group3) chmod g+rx <-- and --> setfacl -m "default:group::rx"
- downloads (usesr1:group3) chmod g+s && chmod g+rx <-- and --> setfacl -m "default:group::rx"
- uploads (root:group3) chmod g+s && chmod g+rwx <-- and --> setfacl -m "default:group::rwx"
This gives the following results
- The "private" folder is owned by user1 and only he and group1 have access to it
- The "public" folder is owned by root and accessible in read-only by group3.
- This means that only root can create/modify/delete file/folders inside this folder but members of group3 can access/read/download them.
- The folder also has the default acl set to "rx" for the group, which means that all files/folders created inside this folder will by default inherit a read-only permission for group3.
- The "public/downloads" folder is owned by user1 and accessible in read-only by the group3.
- This means only user1 can creates/delete/modify new files/folders in this folder but members of group3 can access/read/download them.
- The folder also has the default acl set to "rx" for the group, which means that all files/folders created inside this folder will by default inherit a read-only permission for group3.
- The folder also has the "g+s" turned on which means that all files/folder created by user1 will automatically inherit of the group3 group id
Where I'm having issues figuring it out
- user1 can still delete "private" folder (ISSUE).
- I tried using chattr +i on the "private" folder but it doesn't have the desired effect as it seems that files/folders created inside "private" inherit of that property.
- I am currently working inside a Linux-Vserver and couldn't chattr +i the folder from within the vserver so had to do it via the host (that's another issue but could have it's importance).
- Currently the "public/uploads" folder is owned by root and accessible in read-write by group3.
- This means that user1 and user2 can access/read/download/create/delete/modify new files/folders inside the folder but cannot delete it. (GOOD)
- The folder also has the default acl set to "rwx" for the group, which means that all files/folders created inside this folder will by default inherit a read-write permission for group3.
- The folder also has the "g+s" turned on which means that all files/folder created by user1 will automatically inherit of the group3 group id
- This means that user2 can still download/edit/delete all of the files/folders stored inside "public/uploads" (ISSUE)
- I tried the +t (sticky bit) on "public/uploads" but it doesn't have the desired effect as user1 would not be able to delete files inside anymore.
I'm stuck!
- Changing ownership of the "public/uploads" to user1
- user1 should be allowed to to anything inside (GOOD)
- BUT can now delete the folder (ISSUE)
- Other possible mods
- setting default group acl to rwx (All new files/folders will be rwx for group3)
- setting the g+s (all new files will inherit of group3 group id)
- setting the +t (not tested yet but hopefully will only apply to group and not owner)
- user2 should be allowed to create/modify/delete his own files but not other peoples files (GOOD)
- BUT he will also be allowed to download/view files that he is not the owner of (ISSUE).
Sounded pretty trivial when I started working on this but it seems I've reached my limits for the moment. If anyone has any idea or pointer let me know.
Many thanks in advance, JS