Re: [dev] [quark] Performance issues

From: Anselm Garbe <garbeam_AT_gmail.com>
Date: Wed, 25 Sep 2019 12:05:40 -0700

Hi Laslo,

On Tue, 24 Sep 2019 at 23:22, Laslo Hunhold <dev_AT_frign.de> wrote:
> On Tue, 24 Sep 2019 11:17:09 -0700
> Anselm Garbe <garbeam_AT_gmail.com> wrote:
> > - Always run as current user, if root is used chroot() to current
> > directory.
>
> chroot() should never be optional. unveil() might bring the same
> effect, but the unveil()-wrapper in quark doesn't do anything on Linux.

My thinking is different, I'd rather discourage running quark as root
at all, if it detects uid==0 it should spit out a warning. The only
reason for root privileges would be port 80. Yes chroot() would
require this as well, but actually you should be able to make escaping
from served directories impossible by taking some precautions in terms
of not following links and rejecting .. etc. in urlinfos. The security
measure of operating quark should just be derived from the user that
executes it. That keeps it simple and allows all kinds of surroundings
if desired, and does not rely on its own implementation magic. All it
should ensure that a provided root directory is not escaped.

> > - Always serve current directory as root (no need to supply directory
> > option)
>
> I think that would overstretch it.

By default, there is nothing wrong with supporting -d override similar
to -p override.

> I understand this point, given port 80 cannot be bound when not root.
> But this is a permission thing and that's what doas and sudo are for.
> Especially doas allows you to fine-grain the permissions of specific
> applications.

That's what users are for. doas and sudo are just hacks/workarounds.

> > - Don't support vhosts, if you need that use different server, if you
> > need to run multiple instances, use different ports instead
>
> I don't understand how different ports would solve that problem unless
> you maybe have a relay that is connected to different quark instances
> on an internal network. Publicly, if you have a server serving e.g. 3
> virtual hosts, all accesses have to happen on one port.

Drop in by my definition means one does not run quark permanently, it
is just for temporary stuff. Like during development you serve some
generated documentation through it, or when you want to share some
files for the time being on a LAN. I would always warn about quark not
to be used in any production setup, as it has never been properly
reviewed or pen tested.

With this definition there is really no justification at all to
support vhosts. If you need to serve different directory roots (that
typically may translate to different vhosts in classic setups), just
run different quark instances on different ports, that's the point I'm
making here.

> > - Don't support unix sockets
>
> Agreed, they increase the complexity, but they make quark much more
> flexible. For instance, this makes it very easy to attach something like
> stunnel to it for TLS.

There is no reason to put some stunnel on an INET socket that talks to
a locally only bound quark INET socket. If one really wants to access
quark via a unix socket, use netcat to offer a unix socket to local
inet socket. No need to overload quark for this.

> > - Don't bother with TLS stuff, a drop-in server should not be required
> > to use TLS
>
> quark itself doesn't do any TLS, but it's capable of "dealing" with
> something like stunnel by giving proper redirects and so forth.

That's my whole point. If someone needs TLS, he can achieve that by
putting proxy in front of it.

> > - Eventually add content range support (which might become handy for
> > drop-in use cases)
>
> quark supports partial content. This is mandatory if you serve videos
> or audio files.

Good

> > That's it. I'm sure this can be done within 200 lines. And this should
> > be the aim for quark after all. It shouldn't be supposed to be used as
> > a general purpose server, as said initially, there are enough already
> > to choose from. But there are almost non that offer the feature set
> > described.
>
> The most substantial part of quark is not necessarily the host handling
> or something like directory-choice (the latter is done in like 4 lines
> during the ARG-loop). The HTTP-header parsing alone takes 200 lines and
> handles special cases like this crappy IPv6-bracket-notation which is
> too easy to miss. Another substantial part is actually the
> content-range handling, because it has some intricate details. I get
> your point of course, and in a world with only OpenBSD (sadly it isn't)
> I would strip out vhosts immediately.

If you remove vhost handling you will be able to remove all kinds of
cruft, like redirect handling etc.

> The main problem I see is that there is no "nice" httpd on Linux. We
> might move forward and try to port OpenBSD's httpd to Linux and get it
> packaged. However, up to this point, quark can act as a lightweight
> server even for static purposes on Linux.

There is no nice drop in on Linux or anywhere to the spec I described.
quark could fill this gap.

If I want to run a real httpd on Linux, I'd stick to nginx... but if I
quickly want to serve some stuff until tonight in directory XY, I'd
consider a quark as I described.

BR,
Anselm
Received on Wed Sep 25 2019 - 21:05:40 CEST