It's hard to give precise commands without knowing the O/S or distribution; and yes! ACL would work, but there's a standard way, too.
useradd, one of them on your distribution may create the user's home directory automatically. If so, then the contents of
/etc/skel/ directory would be copied into the the user's home directory, permissions set, and perhaps some other appropriate actions might make place.
There may exist groups pre-defined for sharing, such as 'staff', but if we want to create our own group for sharing, there's nothing wrong with that. So, create a new group or use and existing group. Make sure that users who are to be members of the group have been defined as such with
vigr perhaps, according to your *nix distribution. Each user will need to logout if currently logged in to become a member.
Create a directory common for all users, such as
/home/share_directory/ or any other directory that makes the most sense for your situation. I recommend not using a directory within the user's home directory. If no one but the owner and group should be able to see files in the directory, then change the directory's permissions to 0770. If reading is ok by "others", then use 0775. The owner of the directory should almost certainly be root.
chown root:group_name /home/share_directory/
Next, change the setuid bit:
chmod +s /home/share_directory/
If no user should be able to modify another user's file, then also set the stick bit:
chmod +t /home/share_directory/
These examples set both the setuid and sticky bits at the same time using octal notation:
chmod 5775 /home/share_directory/
chmod 5770 /home/share_directory/
For the updated question, it seems as though ACL is the right tool. It takes a little work, though, to start. First mount the file systems with the acl option in /etc/fstab.
sudo vim /etc/fstab
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx / ext4 defaults,acl 0 1
Remount the filesystem:
sudo mount -o remount,acl /. Then make a group to which a user may belong for this purpose. You may need to install the ACL tools as well:
apt-get install acl.
sudo groupadd developers
sudo usermod -a -G developers $username
(Or the group might be "contractors".) The user needs to log out and in again to become a member of the developers group. Of course, do not do this if you have content in the /var/www directory that you want, but just to illustrate setting it up to start:
sudo rm -rf /var/www
sudo mkdir -p /var/www/public
sudo chown -R root:developers /var/www/public
sudo chmod 0775 /var/www/public
sudo chmod g+s /var/www/public
sudo setfacl -d -m u::rwx,g::rwx,o::r-x /var/www/public
sudo setfacl -m u::rwx,g::rwx,o::r-x /var/www/public
sudo setfacl -d -m u::rwx,g:contractors:rwx,o::r-x /var/www/public
sudo setfacl -m u::rwx,g:contractors:rwx,o::r-x /var/www/public
Above, the difference between the
setfacl commands are these: the first instance uses the default group (group owner of the directory) while the second specifies a group explicitly. The
-d switch establishes the default mask (
-m) for all new files and directories within the directory. Yet, run the command again without the
-d switch to apply the ACL to the directory itself. Then replace references to "/var/www" with "/var/www/public" in a config file and reload.
sudo vim /etc/apache2/sites-enabled/000-default
sudo /etc/init.d/apache2 reload
If we wanted to restrict delete and rename from all but the user who created the file:
sudo chmod +t /var/www/public. This way, if we want to create directories for frameworks that exist outside the Apache document root or maybe create server-writable directories, it's still easy.
Apache-writable logs directory:
sudo mkdir /var/www/logs
sudo chgrp www-data /var/www/logs
sudo chmod 0770 /var/www/logs
Apache-readable library directory:
sudo mkdir /var/www/lib
sudo chgrp www-data /var/www/logs
sudo chmod 0750 /var/www/logs
A liitle bit of "play" in a directory that does not matter should help get this just right for your situation.
On restrictions, I use two different approaches: the shell,
rssh, was made to provide SCP/SFTP access but no SSH access; or, to restrict the use to a home directory you could use the internal-sftp subsystem, configured in
Subsystem sftp internal-sftp
Match group sftponly
Create a group named, for example, sftponly. Make users a member of the sftponly group. Change their home directories to
/ because of the chroot. The directory, /home/username, should be owned by root. You can also set the user's shell to /bin/false to prevent SSH access. Mostly I am concerned about interactive access, so generally go with the
rssh path. (They can't write anywhere except where I have defined write ability.)
On the ACLs, I had forgotten about the nature of Linux ACLs. When using the
-d switch, all new files and directories within a directory with an ACL will use the defined ACLs. However, an ACL for the directory itself must also be applied.
Be wary of the use case for ACLs. For example, perhaps not every SCP/SFTP client is aware of ACLs.