0

On a Debian apache2 server I'm trying to give access on a subdirectory of a webstie tree (Website home dir : /home/website/public_html/, access wanted only for a specific user: /home/website/public_html/boutique/modules/sftpwkmodules

So main website user has access to all tree (userweb).
But I need access for user sfkmodules to the subdirectory inside the tree and it doesn't work.
I created user sfkmodules, and group sftpwkmodules.
I setup these lines in sshd_config file:

Match group sftpwkmodules
    ChrootDirectory /home/website/public_html/boutique/modules/wkmanagesuppliers
     ForceCommand internal-sftp
     AllowTCPForwarding no
     X11Forwarding no

But when I connect to sftp with this user, it isn't allowed. In the log it seems that there is a bad ownership on fatal: bad ownership or modes for chroot directory component "/home/website/public_html/".
But I can't change ownership of all the tree just to have this user access to the subdirectory. Is there a way to make it works?

  • Reason for that sshd restriction. – kubanczyk Mar 24 '18 at 14:25
  • Put the wkmanagesuppliers directory somewhere else and use an Alias statement in your apache config to serve /some/place/else/ as your /boutique/modules/wkmanagesuppliers web directory – ivanivan Mar 25 '18 at 14:47
  • @kubanczyk - wouldn't they need a shell to execute this type of attack? Wouldn't setting teh shell to /bin/false along with the ForceCommand directive mitigate this? – ivanivan Mar 25 '18 at 15:09
  • @ivanivan The shell is ignored here, whatever it is. The concern was actually to put an additional fence just in case of an sshd's remote execution vulnerability. – kubanczyk Mar 25 '18 at 16:02
0

Before changing permissions, be sure to consider that your web server will have to have at least read permissions to the files and directories. Also, any files/directories created by the user sfkmodules will be owned by that user and depending on your umask, may not be readable by the web server.

A solution to consider would be to chroot the users in their own directories outside the webroot and come up with some manner of watchdog to detect when files are dropped and move those files into the webroot. That way, you can control ownership and permissions.

PERL and cron are your friends for that endeavour.

0

Create a group, add the required user to the group along with any other users you want to have access and assign the required permissions. Don't use chroot this time.

Commands below are for CentOS, but you get the idea.

sudo groupadd groupname  
sudo usermod -a -G groupname admin  
sudo usermod -a -G groupname user1  
sudo chown -R admin:groupname /home/website/public_html/boutique/modules/wkmanagesuppliers  
  • Yeah, basicly don't apply The Best Practice mindlessly. This time the chroot wouldn't be an economical choice. By the way, you could usermod user1 to have a home directory of wkmanagesuppliers, it's convenient. – kubanczyk Mar 25 '18 at 11:28

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.