💾 Archived View for rawtext.club › ~sloum › geminilist › 000643.gmi captured on 2020-11-07 at 01:39:22. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Server software recommendations

Sean Conner sean at conman.org
Thu May 14 22:38:54 BST 2020
- - - - - - - - - - - - - - - - - - - ```

It was thus said that the Great solderpunk once stated:
> On Thu, May 14, 2020 at 12:35:45PM +0000, tiwesdaeg at tilde.pink wrote:
>  
> 
> I'm using molly-brown currently, because I like how it handles user
> 
> public_gemini directories. Full cgi support would be nice.
> 
> I've been meaning to write a gemlog about this for ages, but never seem
> to have the time...
> 
> GCI support in Molly Brown scares the pants off me.  Go doesn't reliably
> support setuid() and this totally breaks all the standard pradigms of
> unix server design.  In particular, I can find no way for MB to spawn a
> CGI process which doesn't run as the same user as MB itself, and
> therefore necessarily has the ability to read the TLS private key files
> and write to the log file, which is obviously a massive security hole.
> Because the MB process never runs as root, it's not possible to chroot
> the CGI processes somewhere they couldn't see those files, either

  Does Go actually check the permissions of a file before calling exec() onit?  And refuse to run it if it's setuid?  That sounds strange to me.  Or doyou mean something like?

	child = fork()	if (child == 0) /* child process */	{	  setuid(CGIowner);	  exec(CGIprogram);	}

  And because I feel compelled to state this:  setuid() only works for root.

  And it is possible to chroot programs, but it's not generally done inthese days of dynamically linked programs because you need to copy in allthe shared objects into the chroot with the program.  Hmmm ... I wonder ifyou can't do a chroot with some LD_PRELOAD trickery ... might have to playaround with that.

> I'm frankly baffled that a language with Ken Thompson and Rob Pike as
> designers, created specifically to help Google engineers write server
> software, could turn out to be so terrible for...writing servers on
> unix.

  Rob Pike doesn't trust programmers.  Direct quote from him:

	The key point here is our programmers are Googlers, they're not	researchers.  They're typically, fairly young, fresh out of school,	probably learned Java, maybe learned C or C++, probably learned	Python. They're not capable of understanding a brilliant language	but we want to use them to build good software. So, the language	that we give them has to be easy for them to understand and easy to	adopt.

		http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/From-Parallel-to-Concurrent

> This was the reason that I pondered a few months back on this list some
> kind of FastCGI-esque system for a Gemini server to communicate with a
> process it didn't spawn itself over a domain socket or similar.  But
> maybe I should just give up on Go for servers (this exact same issue
> affects Shizaru, too.).

  FastCGI could be a way of doing it.  I might just look into that forGLV-1.12556 ...

  -spc (There's always Rust ... )