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,
On Wed, 25 Sep 2019 at 23:27, Laslo Hunhold wrote:
> quark drops all its permissions as soon as it has done all the things
> it needs to do. This also includes that you can't accidentally serve a
> root directory. To underline it further, quark _disallows_ itself to
> run as root while serving for
On Wed, 25 Sep 2019 17:03:06 +0200
Markus Wichmann wrote:
Dear Markus,
> You might not, but a library you use might. I remember musl testing
> for open FDs 0, 1, and 2 and opening /dev/null to make up for missing
> FDs. And crashing (deliberately) if that fails. But then, that only
> happens for
On Wed, 25 Sep 2019 12:05:40 -0700
Anselm Garbe wrote:
Dear Anselm,
> 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 we
On Wed, 25 Sep 2019 17:26:32 +0200
Hiltjo Posthuma wrote:
Dear Hiltjo,
> Yes and to add to it:
> Of course unveil and pledge also don't need (initial) root
> permissions, which makes locking down basic programs very easy.
that's what I like about them. Sure, there are good reasons not to
allow
Hi Laslo,
On Tue, 24 Sep 2019 at 23:22, Laslo Hunhold wrote:
> On Tue, 24 Sep 2019 11:17:09 -0700
> Anselm Garbe 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 unve
On Wed, Sep 25, 2019 at 04:32:45PM +0200, Laslo Hunhold wrote:
> please excuse the ignorant question, but why would you want to access
> /dev/null? The problem with /dev/urandom is well-known, which is why
> OpenBSD has arc4random(3).
>
You might not, but a library you use might. I remember musl t
On Wed, Sep 25, 2019 at 04:32:45PM +0200, Laslo Hunhold wrote:
> On Wed, 25 Sep 2019 16:06:52 +0200
> Markus Wichmann wrote:
>
> Dear Markus,
>
> > chroot() has several detrimental effects, most importantly making it
> > impossible to access /dev/null and /dev/urandom. Unless, of course,
> > mea
On Wed, 25 Sep 2019 16:06:52 +0200
Markus Wichmann wrote:
Dear Markus,
> chroot() has several detrimental effects, most importantly making it
> impossible to access /dev/null and /dev/urandom. Unless, of course,
> measures are taken to replicate these devices underneath the new root.
please exc
On Wed, Sep 25, 2019 at 08:20:52AM +0200, Laslo Hunhold wrote:
> chroot() should never be optional. unveil() might bring the same
> effect, but the unveil()-wrapper in quark doesn't do anything on Linux.
>
chroot() has several detrimental effects, most importantly making it
impossible to access /d
On Tue, 24 Sep 2019 21:33:03 +0200
Hiltjo Posthuma wrote:
Dear Hiltjo,
> > Thanks for the insight! I was thinking about using quark instead of
> > OpenBSD's httpd, because it simpler to use and probably even more
> > secure. I think ~1000 requests/second is still plenty for all my
> > projects,
On Tue, 24 Sep 2019 19:58:01 +0200
maillists.rul...@mailbox.org wrote:
Dear Richard,
> Thanks for your assessments! I think you've hit the nail on the head.
> I got my initial test results on an OpenBSD machine. I tested the
> golang server and quark again on a Linux machine today and the
> diffe
On Tue, 24 Sep 2019 21:16:05 +0200
Hiltjo Posthuma wrote:
Dear Hiltjo,
> Sorry to go a bit off-topic here, but I quickly tested and reviewed
> the CGI patch. This CGI patch is broken. A basic `quark -h 127.0.0.1
> -p 8080` serving some page always returns HTTP 400 "Bad request".
>
> A few bound
On Tue, 24 Sep 2019 11:17:09 -0700
Anselm Garbe wrote:
Dear Anselm,
> The issue is, there are enough http servers, but most of them are
> designed as daemons. As you say, quark could become a nice alternative
> for drop-in purporses. For this it is currently too feature rich
> however. I would s
On Tue, Sep 24, 2019 at 10:58:29AM +0200, Laslo Hunhold wrote:
> On Mon, 23 Sep 2019 13:07:47 -0700
> Anselm Garbe wrote:
>
> Dear Anselm, Dear Richard,
>
> > Thanks for doing that and letting me know. So the reason you see this
> > performance penalty in contrast to the other web servers you me
On Tue, Sep 24, 2019 at 07:58:01PM +0200, maillists.rul...@mailbox.org wrote:
> Hi Laslo and Anselm,
>
> Laslo Hunhold wrote:
> > On Mon, 23 Sep 2019 13:07:47 -0700
> > Anselm Garbe wrote:
> > > Thanks for doing that and letting me know. So the reason you see this
> > > performance penalty in co
Hi Laslo,
On Tue, 24 Sep 2019 at 02:02, Laslo Hunhold wrote:
> Quark is actually very lean and offers 99% of the features you would
> expect for a static server. I personally am a big fan of OpenBSD's
> httpd and will use it on the server I am currently setting up.
>
> I see quark's role more lik
Hi Laslo and Anselm,
Laslo Hunhold wrote:
> On Mon, 23 Sep 2019 13:07:47 -0700
> Anselm Garbe wrote:
> > Thanks for doing that and letting me know. So the reason you see this
> > performance penalty in contrast to the other web servers you mention
> > is, that quark is a fork() based web server
On Mon, 23 Sep 2019 13:07:47 -0700
Anselm Garbe wrote:
Dear Anselm, Dear Richard,
> Thanks for doing that and letting me know. So the reason you see this
> performance penalty in contrast to the other web servers you mention
> is, that quark is a fork() based web server (and current HEAD is stil
On Mon, 23 Sep 2019 at 12:50, Richard Ulmer
wrote:
> I checked the performance of revision
> 22b5b3cfa6b28f8e0c6c35c04ad9b4cb609b5643 like this:
>
> echo 'foo bar' > index.html
> doas quark > /dev/null &
> ab -n 1 -c 20 'http://localhost:8083/'
>
> And I got 942 requests/second, so I'd say the
Hi Anselm,
I checked the performance of revision
22b5b3cfa6b28f8e0c6c35c04ad9b4cb609b5643 like this:
echo 'foo bar' > index.html
doas quark > /dev/null &
ab -n 1 -c 20 'http://localhost:8083/'
And I got 942 requests/second, so I'd say there is no significant
difference to the current version
Hi Richard,
On Mon, 23 Sep 2019 at 11:34, wrote:
> I'm toying with quark and noticed it's comparatively poor performance in
> my use case. I used Apache bench to benchmark the web server. With this
> setup I got 980 requests/second:
Out of curiosity, can you do me a favour and check a very old r
Hi,
I'm toying with quark and noticed it's comparatively poor performance in
my use case. I used Apache bench to benchmark the web server. With this
setup I got 980 requests/second:
echo 'foo bar' > index.html
doas quark -d . -h localhost -p 8080 > /dev/null &
ab -n 1 -c 20 'http://localhost:8
23 matches
Mail list logo
