I'm using Debian 7 and have created a new user (website) with an htdocs directory like this:
$ sudo adduser website
$ sudo mkdir -p /home/website/htdocs
$ sudo chown -R website /home/website
Now I'd like users of another group (developers) to have access to the user's directory. I have tried:
$ sudo chown -R :developers /home/website
I can see that the group is assigned (with ls -la
or stat
) and that the users are in the group, but they don't have access right?
drwxr-xr-x 3 website developers 4096 May 3 09:09 website
I also want to:
-
Allow another group, 'contractors' access to website files
-
Restrict access of website users to their home directories only
-
Ensure new website files inherit these permissions
Do you have to use access control lists – or is there a better way to do this (like not using a separate user for each site)?
Best Answer
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.
There's
adduser
anduseradd
, one of them on your distribution may create the user's home directory automatically. If so, then the contents of the/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 an existing group. Make sure that users who are to be members of the group have been defined as such with
usermod
,moduser
, orvigr
perhaps, according to the operating system. Each user currently logged in must logout and back in again to become a member of a new group.Create a directory common for all users, such as
/home/share_directory/
or any other directory that makes the most sense for your situation. A relevant best practice is not to use a directory within any user's home directory. If no one except 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.Next, change the setuid bit.
If no user should be able to modify another user's file, then also set the stick bit.
These examples set both the setuid and sticky bits at the same time using octal notation.
or
For the updated question, it seems as though ACL is the right tool. Most Linux distributions now include the
acl
option in thedefaults
option. If your distribution doesn't include theacl
option by default, then this a little work is needed to start using it. First mount the file systems with theacl
option in /etc/fstab.If needed, 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
.(Or the group might be "contractors".) A currently logged in user must log out and back in again to become a member of the new group. Of course, do not do this if you have content in the /var/www directory that you want to keep, but just to illustrate setting it up to start:
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 filesystem objects within the directory. Yet, we also need to 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.If we wanted to restrict delete and rename from all except 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:
Apache-readable library directory:
A litle 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/etc/ssh/sshd_config
.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 therssh
path. (They can't write anywhere except where I have defined write ability.)