0 votes
by Talented
Has anyone sorted out a way to allow additional user accounts that have SFTP access only to specific sites/folders within a server?

I can add the additional accounts. I can add passwords and set up SFTP access. What I can't figure out is how to assign permissions to the site directory in a way that (1) allows a user to have a specific folder set up as their SFTP root while (2) also allowing WordPress access to write to the uploads folder.

In short, I got as far as locking everything down properly from the SFTP side, but that seemed to prevent WordPress from accepting file uploads since the folders were owned by a different user.

To anyone who's sorted this out - if you don't have time to share details about how to set this up properly, I'd at least settle for knowing that it's technically possible. I'm unsure if the fact that the various server processes run as www-data user totally precludes us from managing files via SFTP in this manner or if I've just yet to stumble across the proper file ownership configuration to make it all work.

BTW QROkes I've seen several places where this topic has been brought up and I understand you don't support it any official capacity, so please understand I'm not asking for that at all. I'm not interested in this from the strict security standpoint others have mentioned (i.e. a hack taking down all the sites on the server), I'm more interested in this from a practical/usability standpoint (I want to be able to give certain team members access to a site without fear that they'll accidentally goof up something across other sites)

Thanks all!

2 Answers

+1 vote
by Rookie


if you want your uploads folder to be accessible both by user and www-data, you should 

  1. chown it (recursive) to www-data:usergroup (the user should be a member of that group - typically a group with the same name as the user is automatically created when you create a user on debian based systems)
  2. chmod your uploads folder recursively like this: chmod -R g+Xw uploads (allow group to list directories and write - the X is execute directories only)
As recommendation I would suggest to disable php in the uploads folder in your nginx/apache if not already done.
Hope this helps, 
regards, Greg
by Expert
Maybe there is something I'm not seeing, but I don't really understand to all of those users complaining about having separate PHP and SFTP users for each site.

The best isolation you can have (if isolation is a concern) is having a different VPS or Dedicated Servers for each site. You can find a VPS for prices lower than $3 or $4usd per month, if your site not worth it, I don't understand why people spend so many time trying to find a solution, actually cPanel and shared hosting do an excellent job on this field.

Webinoly is focused on performance and having multiple users is not in our roadmap, in fact, I think it's out of the scope of this project. Also, the Free and Open Source version of Nginx does not include this feature, people that are telling they have this feature is because they are compiling their own Nginx, hacking some functionalities and adding extra-modules that end up over-optimizing your server with unexpected results. I don't trust in these solutions!

Best regards and be careful about the "stack" you choose.
by Talented
edited by
Hey QROkes - I'm certainly not complaining... I LOVE webinoly and greatly appreciate the effort that's gone into it. I simply didn't realize until now that there wasn't some level of protection/isolation between the sites on a server.

My use case for the SFTP users is, admittedly, an edge case - thus me simply endeavoring to learn as much as I can and figure it out instead of being upset that webinoly doesn't include it.

That said, I don't think it's unreasonable to desire isolation between the sites themselves on the file ownership/PHP side such that a compromise from bad code in one site doesn't impact other sites running on the same server. I know you're a big proponent of choosing plugins, etc carefully to avoid the root cause of this, but most users are not capable of scouring a plugin the way you are to find vulnerabilities or bad practices. It seems prudent to me to provide whatever protection we can against such compromises.

Overall, I think there's just a general expectation (whether it's right or wrong is up for debate) that for a tool that is designed to generate multiple sites, the sites it creates should be secure.

Otherwise... what's the point of generating multiple sites? If the only way to create a secure site is to launch it on a separate VPS, why doesn't webinoly just create/manage a single site only and make it clear that it's a one-site-per-server kind of tool?

Those are rhetorical questions - I'm just trying to provide insight into the mind of an actual webinoly user who thinks "Awesome, I can manage multiple sites on a single server" only to find out that it's not a best-practice to do so.

Even for my own internal sites (with me as a single admin/developer/sftp user), I'd be hesitant to put more than one site on a server knowing that a compromise in one equals a compromise in all.

I admittedly haven't scoured the documentation, but have made pretty extensive use of it in my 6+ months with webinoly and have never seen anything there to indicate that it's a bad idea to power up multiple sites in a single server. So perhaps a lack of education/warnings around this topic in the documentation may also be to blame for requests to utilize webinoly in a way that it's not intended.

I totally get it - multiple sftp users/fpm pools is not something webinoly has or that you plan for it to ever have, and even if I don't fully understand it I respect your decision to not include it. I'm just trying to explain where I think some of the disconnect is between the tool you've built and the way people are using it.

As you said - costs are minimal for a VPS and we'll be using webinoly in a single-site-per-vps manner from here on out. It's not a deal breaker at all, just something that I (and many others, I'm sure) needed to be educated on to fully understand it.
by Expert

Just to clarify, I never said that Webinoly is for a single site. What I said is that if isolation is a concern for you, the best method is having a VPS for each site.

The thing is very easy:

  • You can host as many low traffic websites in a server as you want, obviously, all depends on the traffic, RAM, and CPU available. Backups and recovery scripts are always recommended, just in case of something went wrong.
  • If you have a big, high traffic or priority site, you should always use a single VPS for it, it's common sense.
  • You need Nginx Plus (Not Free) if you want an optimal solution for multiple users. Be careful of the people offering Nginx (free and open-source version) servers with support for multiple users, I'm sure they are compiling their own Nginx, adding modules and hacking things to get it working. As I said before, I don't trust in this kind of solutions.
  • If you own all the websites, it not make sense having multiple users. If you want to have a shared hosting environment with multiple users, go with cPanel or similar, that's my recommendation.
  • All of those websites in a VPS are usually managed by the same owner. What do you want to hide from one site to another that are both yours? In shared hosting makes easier the resource management for each user, in a VPS is the same, all the resources are all for you.
And believe me, if someone wants to hack your site/server, having dedicated users will not stop to these guys, maybe it will be one minute more to do it.
by Rookie
I will just write here my usecase where Webinoly is perfectly safe and has enough isolation. I provide people with managed Wordpress sites. My promise is: I take care of the code, you take care of the content.

I manage all the plugins and cores with wp-cli and I take advantage of the possibility of writing scripts, to help me with that. I as a unix user am the owner of all of the code, so www-data can't write to any of the folders except for the ones where php is disabled (Uploads and certain languages folders).

This makes my stack pretty safe but it also disables the possibility to install/update themes/plugins/core from the wp-admin section, which is ok with me, since my clients only want to control the content, while I use wp-cli for that.

For this matter Easyengine before, and now Webinoly is the perfect tool (with the exception of one patch I have to make). The official Easyengine 3 fork called WordOps has several downsides compared to Webinoly: the development is less dynamic, it still has some caveats easyengine was struggling with and, crucial for me, it is written in python. It would only make sense to me, that a script intended to manage php sites would be written either in php or in bash. I don't particularly love bash, but it has an upside of being easy to understand.

The one upside of WordOps is a bigger company and team behind it, making its development more stable in the long term. Webinoly has bus factor = 1, meaning if QROkes gets hit by a bus, we are all screwed. However, since the code is pretty well organised and neat (kudos to QROkes for that!), forking and maintaining it wouldn't be as much of a problem.

This is why Webinoly is usefull, secure and makes sense to me. It all depends on the usecase, how you work and what you want.
by Talented
Thanks fellas, I appreciate the dialog and insights :D
0 votes
by Rookie
Welcome to the Community site for Webinoly.

If you have a question about Webinoly, please ask in English or Spanish.

To report a bug, please ask a question here with the bug tag.

News: Now you can use any external SMTP service in your server. All the server outgoing emails from any of your websites will be sent through this service.


Webinoly Support Paypal Donations Webinoly Support Bitcoin Donations

Your regular donations is what keep this project moving forward. If you like Webinoly, buy me a coffee or a beer to show support.

Affiliate Links

It is very important that any visitor to the site read the disclaimer, terms of use and privacy and legal statement before start browsing.