Re: [dev] [quark] Performance issues

From: Laslo Hunhold <>
Date: Fri, 27 Sep 2019 07:59:00 +0200

On Thu, 26 Sep 2019 07:38:01 -0700
Anselm Garbe <> wrote:

Dear Anselm,

> When I imagine quark as a drop-in / on demand temporary http server, I
> would just imagine it'll assume the privileges/capabilities of the
> user/group that is running it.
> If I want it to have very rigid/limited permission, I'd execute it
> with that user context rather hoping for it dropping privileges. Often
> assuming a user requires root privileges, here the rotten concept
> already starts. I want a permission and execution model, that is
> imposed from the start. Dropping privileges is possible from the
> surroundings that start it -- assumed creating a socket etc. is a
> valid capability for the assumed user.

that's how the ball rolls unfortunately. I would never consider using a
server which does not chroot() or jail itself in some other way, let
alone developing it. And unfortunately, many of those jails require
high permissions.

But I get your point.

> > > 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.
> >
> > I support your point with regard to OpenBSD. On Linux, it is a
> > different matter, as there is no real suckless server that I know of
> > which also provides the security we are used to from OpenBSD's
> > httpd.
> Did you check ?

Well, it's using setuid, which is pretty horrific for a server. If your
server is setuid and anyone can use it, you can easily use it to grab
data from other users on a multiuser system. As I said earlier, the
only "sane" solution is to use doas(1) and sudo(1).

> The issue is you have to resist the feature load if quark is serious
> about becoming THE drop-in option. Only tools that serve a single
> purpose and maintain it rigidly are successful in the long run.

I agree with that point and will think about dropping features.

> Don't get me wrong, but I have been there and I have become way more
> sceptical than this, with such claims. Often security flaws requiring
> imagining the un-imaginable. In case of lazy clients or DDoS quark
> might not become insecure itself, but screw other stuff on a server
> etc. A truly safe and secure setup may require special rate limiting
> on the firewall as well or specific request pattern processing in
> terms of rigid timeouts etc. Unfortunately a (too?) simple
> implementation can't address some of these cases, so for the sake of
> simplicity it's good to declare the limits, which is why I'm
> advocating the drop-in use case here. Nobody will expect a tank with
> backup artillery when he orders a taxi. ;)

Haha that's a great analogy! Well, a DoS could happen, I was more
thinking about data leaks or something

> Easy, just run two quarks, one on 8080 the other on 8090 and then tell
> your clients and

The "default" port is still 80. :P

> Why would you give a fuck about those? If it's a drop in it's not
> supposed to canonicalize to permanent redirects and temporary
> redirects aren't needed either.

Just because something is a drop-in doesn't mean it should be sloppy to
save 50 lines of code.

> > I see what you mean. Sadly nginx has become a bloated mess.
> It has become more bloated, but it's still pretty lean in comparison
> to the abominations called apache or IIS ;)

That's true!

With best regards

Received on Fri Sep 27 2019 - 07:59:00 CEST

This archive was generated by hypermail 2.3.0 : Fri Sep 27 2019 - 08:00:39 CEST