1

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

  1. 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
  2. user2 should
    • have no access at all to this folder/subfloders and files

"public" folder

  1. user1 should
    • not be allowed to delete the "public" folder but be allowed to browse it.
    • not be allowed to write inside "public" folder
  2. 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

  1. 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
  2. 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

  1. 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
  2. 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

  1. The "private" folder is owned by user1 and only he and group1 have access to it
  2. 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.
  3. 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

  1. 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).
  2. 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
  3. 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!

  1. Changing ownership of the "public/uploads" to user1
    • user1 should be allowed to to anything inside (GOOD)
    • BUT can now delete the folder (ISSUE)
  2. 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

0

Here is a directory structure that should do what you want.

# file: .
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

# file: public
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

# file: public/uploads
# owner: user1
# group: group1
user::rwx
group::r-x
group:group3:rwx
mask::rwx
other::---
default:user::rwx
default:group::r-x
default:group:group1:rwx
default:group:group3:---
default:mask::rwx
default:other::---

# file: public/downloads
# owner: user1
# group: group1
user::rwx
group::r-x
group:group3:r-x
mask::r-x
other::---
default:user::rwx
default:group::r-x
default:group:group3:r-x
default:mask::r-x
default:other::r-x

# file: private
# owner: user1
# group: group1
user::rwx
group::rwx
other::---

The important differences are: The base directory and public are owned by root. This way private and public/* are not deletable by user1. public/uploads has default:group:group1:rwx and default:group:group3:---. This way user1 can do everything but user2 can do nothing with new files in that directory except for his own files.

  • First of let me thank you as this is a lot more than I had expected. I'll be testing this today and will update the post accordingly. The important info I was missing was the fact that one can apply different default acls for different groups on a same file. Thank you. – JayC Oct 25 '13 at 7:30
  • Adjustments made, testing successful, works as advertised. Thank you so much Micheal for this very useful heads up on using acls as well as for the solution provided. – JayC Oct 25 '13 at 15:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.