Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Our SFTP share is set in: /home/COMMUNITY

Each workgroup has its own directory, for example: /home/COMMUNITY/Halloween

This directory has multiple directories under it. There is one group that contains all users: COMMUNITY. All directories have with sticky bit set as group owner COMMUNITY, this works well and all directories and files created in this structure have automatically this group.

Individual directory rights for SFTP users are controlled by the directory group. In case of /Halloween it is the group HALLOWEEN. Users login with SFTP start in /home/COMMUNITY. This works well when only one user per directory was working on a community project. However our community service group is growing and have more users per group HALLOWEEN for example and here things go wrong. A directory of file created by a user gets automatically his/her ownership as is default. But for our system to work well the ownership of the underlying directories and files must be root.

Maybe flawed but our current thought is to fix this with a shell script that first test if a directory/file has root as owner and if not it will be changed to root. We need to do this recursively under the COMMUNITY directory. We want to keep this very fast and not force to change files that have root already as owner. People sharing documents may create issues but when we run the script frequently we hope it fixes our current problems that users cannot save documents created by other users.

Articles: "Bash Script To Repair Directory and File Ownership", "SFTP jail & Keeping file ownership the same / File owner per folder" and "Sticky Bit Tips" are close to what we want but it not 100% the same and we can not figure it out how to make it work.

Your help is greatly appreciated by all our volonteers who use this system and are now getting frustrated that it does not work quite right anymore.

share|improve this question

1 Answer 1

This actually sounds like you need to look at the default umask, rather than worrying about chown()'ing files. The root user can read anything, period (unless you drop SELinux into the mix, but that's another dissertaion). Most modern linuxes have a default umask of 022, which means you get 755 permissions on new files. You want 002, to get 775 permissions, which will keep group ownership (via the directory sticky bit you've already set) and group write permissions. The user owner will change around regularly, but that shouldn't be a concern.

share|improve this answer
    
When I run sestatus it is not recognized so the original sysadmin did not use SELinux on top of CentOS. We have a system where Chroot does not want to work and have system users. –  GJZ Nov 15 '12 at 21:08
    
Users start at 500. # By default, we want umask to get set. This sets it for login shell # Current threshold for system reserved uid/gids is 200 # You could check uidgid reservation validity in # /usr/share/doc/setup-*/uidgid file if [ $UID -gt 199 ] && [ "id -gn" = "id -un" ]; then umask 002 else umask 022 fi –  GJZ Nov 15 '12 at 21:10
    
@GJZ I don't believe sftp counts as a login shell. if you're using internal-sftp in sshd > 5.4, you can edit your sshd_config to use Subsystem sftp internal-sftp -u 0002 –  DerfK Nov 15 '12 at 22:04

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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