3

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)?

  • Does the group have permission for /home/username? And for the files (and subdirs) in /home/username/htdocs? – Hauke Laging May 4 '14 at 23:44
  • I used sudo chown -R :group /home/username and when I ls -la on /home/username I see the group name listed - if they're listed does that mean they have access? Also, I (rightly or wrongly) assumed that the -R filtered down to all directories within /home/username. Sorry, I'm quickly discovering that the basics are rather complex. – CMSCSS May 4 '14 at 23:54
  • Add the output of ls -dl /home/username /home/username/htdocs to your question. Group and permission are different things. – Hauke Laging May 5 '14 at 0:00
  • @Christopher, sorry I thought :group was the syntax for adding a group! But I get it now it should be chgrp -R group_name directory_name – CMSCSS May 5 '14 at 0:59
2

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 and 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 usermod, moduser, or 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/

or

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 /etc/ssh/sshd_config:

Subsystem sftp internal-sftp

Match group sftponly
  ChrootDirectory /home/%u
  X11Forwarding no
  AllowTcpForwarding no
  ForceCommand internal-sftp

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.)

Update

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.

  • Thanks heaps Christopher - have updated the question with more info. Does your answer hold true if I would like: 1) to grant access to users of two groups (developers and contractors) to the website home directories? 2) If we want new files to inherit the permissions of the parent when we add new files to the website? 3) And want to restrict the website users to their home directories? Will look at your answer in more detail now, cheers. – CMSCSS May 5 '14 at 1:06
  • No, I just didn't want website users to have access to other website users. Maybe this isn't required but it just made sense to me! As you can tell I don't fully understand how all this works - like if Apache is serving from /home/user/htdocs do I need to grant access to Apache as well (does Apache have a user)? – CMSCSS May 5 '14 at 1:14
  • Lets put this another way! How would you set up a secure web server with the developer and contractor access I'm describing? – CMSCSS May 5 '14 at 1:50

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.