On Wed, 25 Sep 2019 12:05:40 -0700 Anselm Garbe <garb...@gmail.com> 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 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. 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 this precise reason (and the reasons discussed earlier not to escape the chroot). > That's what users are for. doas and sudo are just hacks/workarounds. quark doesn't explicitly require root. If you solve this problem with capabilities or whatnot you don't need root and quark won't complain. > 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. With regard to security: I see no way quark could be exploited after the permission drop. It only has read-only access (by unveil()) to the serve directory that we can assume not to contain secret information anyway. Even if there was some exploit within the serve()-step, you can't really do much damage. > 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. So how would that work if I wanted to serve both the domains "domain1.org" and "domain2.org" with quark? Both requests go to port 80. > 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. That is a good point! I'll think about it. > > quark supports partial content. This is mandatory if you serve > > videos or audio files. > > Good To add a point here, this feature is almost always missing from the other "light" servers. > If you remove vhost handling you will be able to remove all kinds of > cruft, like redirect handling etc. That's not true. We need to have redirect handling to "discard" non canonical requests, and other things. > 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. I see what you mean. Sadly nginx has become a bloated mess. With best regards Laslo
