Made ghost run without root privileges even when it was run with sudo. #1639

Closed
wants to merge 1 commit into
from

Projects

None yet

8 participants

@kksharma1618

closes #1638

  • added code which changes uid of process after server has been started.
@kksharma1618 kksharma1618 Made ghost run without root privileges even when it was run with sudo.
closes #1638
- added code which changes uid of process after server has been started.
5f2cc76
@ErisDS
Member
ErisDS commented Dec 12, 2013

I think it was decided that this should only be done when configured?

@kksharma1618

@ErisDS I actually closed that issue. Are we making it so that it is configurable? Or should I close this too?

@ErisDS
Member
ErisDS commented Dec 12, 2013

I was just checking before closing this PR. It is something we could make configurable if it is really needed, but it is not a feature that has ever been requested before, so I would like to hold off and revisit it in future if it is clearly needed. It may be possible to do with an app, rather than a change to core, which would be preferable.

@ErisDS ErisDS closed this Dec 12, 2013
@kksharma1618

Yep. Sure

@shelleyp

There has been, now, more than one request for this capability, yet I don't see whether there is activity on this or not, since every issue related to this request is closed.

Apache, which is probably the web facing application with the most exposure and use in the world, runs on port 80 without root privileges by removing said privileges after the application is started. This is a sound, tested, standard approach.

Having to use extraordinary methods to allow the application to run on another port is not conducive to easy and open acceptance of Ghost as anything more than a novelty for geeks.

Worse, encouraging people to run the application on port 80, with root privileges, encourages bad security practices.

Is there an alternative I'm missing here in my understanding of the points?

@jgable
Member
jgable commented Jan 31, 2014

Apache, which is probably the web facing application with the most exposure and use in the world, runs on port 80

@shelleyp Ghost is not Apache (a web server), Ghost is a Node application. Apache is but one of many different web servers that can be used to host web applications. What you are describing can be achieved with nginx and in fact Hannah has made a guide on how to do that.

Worse, encouraging people to run the application on port 80, with root privileges, encourages bad security practices.

We don't encourage people to run the application on port 80, we actually encourage people to run on port 2368 (via our config example) and use nginx to proxy to port 80.

Having to use extraordinary methods to allow the application to run on another port is not conducive to easy and open acceptance of Ghost as anything more than a novelty for geeks.

We have a lovely hosted platform if you'd like to not learn anything new and just leave it to the "geeks".

@shelleyp

Why force people into having to use nginx when it's not overly complicated to provide a configuration option to remove root privileges when running on port 80?

What advantage does a person receive by now having to install and configure two applications, rather than one?

@shelleyp

Ghost is, by its nature, both web server and application. That's the nature of the beast in this particular implementation. If Ghost can't handle the web server aspect than exactly what benefit does it provide for anyone other than curious geeks with extra time on their hands?

@jgable
Member
jgable commented Jan 31, 2014

Why force people into having to use nginx when it's not overly complicated to provide a configuration option to remove root privileges when running on port 80?

Why force people to use Apache?

What advantage does a person receive by now having to install and configure two applications, rather than one?

When you configure Apache, is that not also configuring two applications? I don't run Apache, so forcing me to use it would require me to install and configure another application, right? There are more people on Earth than just you and your particular web domain knowledge.

Ghost is, by its nature, both web server and application

You keep using the word web server, but I don't think it means what you think it means. A web server hosts web applications, Ghost is a web application (does not host other applications).

@hillct
hillct commented Jan 31, 2014
There is certainly something to be said to providing instructions 

for port forwarding, using ipTables, windows firewall, and other common
systems, such that users seeking to deploy Ghost can run it without root
privileges. There is the argument that anyone seeking to deploy it on a
given platform for production use would already be familiar with the
port forwarding capabilities of that platform but it may be worthwhile
to provide documentation for the most common use cases.
With regard to nginx, it's always reasonable to provide a proxy for
static content in cases where you have a server/application structure as
node based application are. While Node/Connect/Express can handle
delivery of static content, light weight servers like nginx or lighttpd
handle that functionality far more efficiently. Similarly it might be
worthwhile to provide documentation of sample configurations utiliing
http://varnish-cache.org or similar cache/load sharing tools.

-- Colin

On 1/31/14, 11:39 AM, Shelley Powers wrote:

Ghost is, by its nature, both web server /and/ application. That's the
nature of the beast in this particular implementation. If Ghost can't
handle the web server aspect than exactly what benefit does it provide
for anyone other than curious geeks with extra time on their hands?


Reply to this email directly or view it on GitHub
#1639 (comment).

@shelleyp

If this were a high-end commerce application, then yeah, I would expect the end user to be proficient in iptables.

But this is a simple blogging tool. Simpler than Wordpress, far simpler than Drupal.

You keep saying it's an application, like Drupal is an application. The point I'm making is see this
"application" from the perspective of an end user, just wanting to get a weblog up and running.

Ghost then becomes both application and web server.

@jgable
Member
jgable commented Jan 31, 2014

There is no mention of iptables anywhere in any of the guide information I've linked, what @hillct is mentioning is an advanced optimization technique most people will not need to do. Configuring nginx to run your node is a pretty standard practice in the node world.

Drupal is an application, that requires a web server like Apache, nginx or IIS. The same way Ghost does.

And once again, we have a very easy hosted option for anyone who does not want to get their hands dirty.

@shelleyp

You all need to make the application/web server dichotomy more apparent as part of your documentation requirements, then.

You should make sure all of your documentation notes that Ghost is not a stand alone product and requires a reverse proxy in order to function in a production environment. It's essential, then, that people not even bother with installing the application if they don't have Apache or nginx installed as web server.

@shelleyp

And the point I've been trying to make is: what are the dangers associated with providing this configuration change? What vulnerabilities are introduced that makes it an unattractive proposition? What are the technical limitations, challenges, or other criteria that make this an unfeasible change?

And the answers I've received are: no one has asked for it, everyone in Node knows about ngnix, and if it's too complicated for you, we'll host it for you.

@shelleyp

Oh, and PS?

Ghost and Drupal are not the same. You can't run Drupal without a web server. Ghost can. When it is, then it is both application and web server. You all just don't want people to use it as a web server.

That's a big difference.

@javorszky
Member

@shelleyp, there are numerous walkthroughs that tell you how to install / setup Ghost on just about anything ranging from amazon ec2s to raspberry pis to digital ocean, etc... Just take a look at https://ghost.org/forum/installation/.

If you read the docs (particularly this page of it: http://docs.ghost.org/installation/deploy/), then you will also notice, that Ghost's official (not community generated) documentation also contains information about how to get your blog live, and references a number of tutorials on how to do it.

But just to get it straight:

  • Ghost is a blogging platform, a web application that runs on nodejs
  • nodejs is server side implementation of javascript (very crudely simplified), that can be used as a web server (amongst other things). Think of it as PHP for Drupal or WordPress with some added niceness.
  • nginx and apache in this instance are proxies that take public facing web traffic and channel it onto what Ghost runs on (2368 by default)

And yes, Ghost has a hosted platform, where all the technical details are taken care of.

Bottom line: if you want to host it yourself, fine, read the documentation about it please (there is plenty of it). If you don't want to host it yourself, you're welcome to use the hosted platform.

@shelleyp

By not answering my questions as to the technical reasons refusing to make this change, I'm having to assume there is no specific technical reason for not providing a configuration option allowing a person to run Ghost directly on port 80—you just don't want to do so. And that's fine, if a little underwhelming.

And just a quick FYI: I am aware of what nodejs is, and how all this technology works. I had planned on writing about Ghost, but will now do so noting it is a tool to experiment with if you're interested in Node development, only. And that's fine, too.

@CWSpear
CWSpear commented Jan 31, 2014

@shelleyp You think that if something is technically possible, it should be done? I'm a little unclear why non-technical reasons aren't acceptable. You seem to only want technical reasons. Yes, it's technically possible to run a Node app on port 80. But it's pretty clear that everyone in the thread feels like it shouldn't.

@jgable
Member
jgable commented Jan 31, 2014

@shelleyp Here are some technical reasons taken from a quick google search on why you should run a web server in front of your web app:

  • Part of any web application is fully standardized and commoditized functionality. The mature web servers like nginx or apache can do the following things. They can do the following things in a way that is very likely more correct, more efficient, more stable, more secure, more familiar to sysadmins, and more easy to configure than anything you could rewrite in your application server.
    • Serve static files such as HTML, images, CSS, javascript, fonts, etc
    • Handle virtual hosting (multiple domains on a single IP address)
    • URL rewriting
    • hostname rewriting/redirecting
    • TLS termination (thanks @emt14)
    • compression (thanks @JacobusR)
  • A separate web server provides the ability to serve a "down for maintenance" page while your application server restarts or crashes
  • Reverse proxies can provide load balancing and fault tolerance for you application framework
  • Web servers have built-in and tested mechanisms for binding to privileged ports (below 1024) as root and then executing as a non-privileged user. Most web application frameworks do not do this by default.
  • Mature web servers are battle hardened and stable. By stable, I mean that they quite literally almost never crash. Your web application is almost certainly far less stable. This gives you the ability to at least serve a pretty error page to the user saying your application is down instead of the web browser just displaying a generic "could not connect" error.

Do any of those technical reasons sound reasonable?

@jgable
Member
jgable commented Jan 31, 2014

Most web application frameworks do not do this by default.

This seems to be what you're getting after and trying to get us to do now. There's a good reason most don't do this, because it's extremely hard to do for all the platforms that could be supported.

The problem with this PR is that it's extremely OS specific. I think it's going to be very complex to detect and handle this situation for all the OS's we support. I personally think it's not the job of our app to make sure your permissions are set up correctly, that's something that your environment will largely dictate.

@shelleyp

@jgable, and nginx is also vulnerable to DoS attacks

http://xforce.iss.net/xforce/xfdb/84172

Everything on the web is vulnerable to attack. If Apache and nginx waited to roll out to when they weren't vulnerable, well, our lives on the web would be short, and not too sweet.

The technical reasons you give for not depending on Ghost as web server seem, to me, to be more reasons not to use Ghost, period. But that's just my perception.

@CWSpear the people responsible for the tool have final say on what does or does not go into tools. If the Ghost folk don't want Ghost to face the world without having a web server in front of it, that's up them.

I would hope, though, that the folks behind Ghost would have sound technical reasons for their decisions, regardless.

Perhaps @kksharma1618 has the best take on it.

@javorszky
Member

@shelleyp, Ghost can, and does face the real world without a proxy a ton of times. Like when I develop on my own computer. The one I'm running on my ec2. It CAN, and it DOES. However, it comes with the inconvenience of either having to run it with root privileges (because port 80 is a privileged port on unix systems, thus needs root), OR having to enter :2368 on the link.

Ghost's been downloaded 120k times roughly. If you want to come up with excuses on why you don't want to use Ghost, fine. Do not use Ghost. We're perfectly happy that huge mass of people are happy with it. And they understand the technical reasons behind our decisions. For the record, @jgable's summary on why we recommend apache / nginx went far beyond what I would have expected of him.

Please read up on technical bits before arguing. Please. We built this thing. There is a reason for all our decisions.

@shelleyp
shelleyp commented Feb 1, 2014

I suggest you look up my name before saying something like "read up on the technical bits".

There's a reason why I'm trying to dig a bit beneath the surface.

But your tool, your choices. Thanks for your time.

@javorszky
Member

Awesome, congratulations on the fame. In light of that though, I don't understand why you don't understand our reasoning even more.

@JohnONolan
Member

Shelley is more than entitled to her opinion, and everyone else is entitled to theirs. Not everyone the internet agrees with each other. And that's quite OK.

Let's try not to get personal about it. There are probably more productive things we could all be doing.

@ErisDS
Member
ErisDS commented Feb 1, 2014

The aim for Ghost is to be a light-weight node-based blogging application. The standard / recommended setup is to use Ghost with nginx as a webserver, and use upstart to keep it running. The documentation aims to cover this, and the DigitalOcean droplet, which was the first officially recommended way of running Ghost is configured this way. This is not the only setup, but it is the one that we consider to be the best for most production environments.

Ghost does not intend to be a fully-featured web server. Stand-alone, it can't deal with static assets as efficiently as a dedicated web server, and it means you lack configuration options for things like url-rewriting and headers and other basic things that you would expect from a web server. It is true that by the very nature of it being a node app, that it can be standalone, but this is not a setup that would ever be officially recommended for the reasons outlined above.

There are a few problems with adding this PR. To start with it is OS specific, and Ghost is intended to work on any OS that can run node. It also seems to me to be an unexpected side-effect, so is not something that should just happen without being configured to. Additionally, it advocates the idea of running Ghost standalone. We'd effectively be opening ourselves up to having to support all the features that people expect from a web server, and that clashes completely with our aim to keep a narrow focus on content publishing.

In the same way that if you want comments, Ghost requires you to use disqus or some other product where the full focus is comments, it is the same with using a web server. Rather than us hacking in a couple of half-baked features just to make it possible, we advocate the use of a product/service that is dedicated to the purpose. This is the Ghost principle - we keep our focus on making the best possible blogging platform, and don't try to do what other people are already doing better.

All this considered, if there was a clear and definite need for the feature, then we would reconsider it as an option, but so far the people who have asked for it seem to be asking it because they had an expectation that Ghost would work this way, rather than having a clear need for it to work that way. This is why the issues are closed, not because they aren't open for discussion, but because there isn't a perceived need for them to be worked on.

@shelleyp
shelleyp commented Feb 1, 2014

@ErisDS thank you for the thoughtful reply. What you say makes good sense, and also gives an understanding of direction and overall architecture of the application.

I can understand wanting to keep Ghost lean, and defer to other battle-hardened resources rather than re-invent the wheel.

I would suggest a look at the documentation associated with installing Ghost on Linux. Right now, this direction isn't necessarily easily discerned in the documentation, and folks are making decisions that may not be wise.

The reason I came to this issue is I'm writing about Ghost and when I start writing about a technology, I do searches to see how people are using the tech, and the problems they might be having. One of the major problems does seem to be the installation on Linux.

The problems people are having are split between those trying to figure out why they can't access Ghost after starting the application up on port 80 without root, and those trying to figure out how to access the app on port 80 without running the app with root privileges.

In both cases, the advice given is a bit scary, including advising people how to use sudo (to run on port 80) and iptables or other mods for people who have figured out that maybe running a web-facing app as root isn't a good idea.

Case in point

http://www.howtoinstallghost.com/how-to-install-ghost-on-godaddy/

The only reference to the philosophy you've outlined well in your comment here is a section tagged at the end of the documentation, about setting up Ghost on a domain. And that really doesn't expose any of the concerns expressed in this discussion.

Even now @kksharma1618 is talking about a plug-in that removes root privileges and allows Ghost to run stand alone. That has potential to be a very popular app in Linux, and it's a good chance most of your installations will be Linux-based. So you might want to extract the discussion about running Ghost stand alone from these discussions and elevate it to a higher level to stop problems before they start.

Just a suggestion.

@shelleyp
shelleyp commented Feb 1, 2014

One last, sorry:

Remember this is a weblogging tool. People have expectations about weblogging tools. More importantly, weblogging tools are used by people with wildly different tech backgrounds. You can't make assumptions that the people using Ghost are only experienced Node developers. You need to be really clear about the environment and expectations of the environment, because you're going to get folks wanting to install Ghost who have only developed in JS in the browser and dabbled a bit with Node.

@ErisDS
Member
ErisDS commented Feb 1, 2014

I don't disagree with you at all that our documentation leaves a lot to be desired. Unfortunately, most people tend to want to write documentation for their own site / blog rather than contribute to the official docs, which leaves it as one of the many under-attended things on my own extensive todo list. That's not an excuse, just a reason why our documentation hasn't improved as much as our code has.

To that end, I have to point out that the documentation is right here in this very repo, and if, as a technical writer, you felt able to help us improve it, that would be very much appreciated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment