So you're suggesting that a user could write code containing a race, have that code produce, say, a slice with the wrong length (by interleaving the pointer and length/capacity writes), and then use that "mixed" slice to compromise the system. I see what you're saying.
If the site is running on a single CPU core, we would have to have the go runtime switch goroutines in the middle of a slice (ptr, len, cap) slice write. I'll have to see if that's possible. Thanks! On Sunday, November 13, 2022 at 12:38:50 PM UTC-8 matt....@gmail.com wrote: > Sounds fun! > > Go doesn't prevent race conditions and those can result in undefined > behavior, so I don't think you're safe just restricting imports and > limiting CPU and memory. You need to run code in a sandbox of some sort. I > would look at what the Go playground does. > > On Fri, Nov 11, 2022, 10:47 BUGFIX 66 <bugfix.s...@gmail.com> wrote: > >> Still under construction: https://BUGFIX-66.com >> >> Site is intended to be like the book Hacker's Delight, but as a game. >> >> Or like professional programming, where you're mostly trying to >> understand/modify other people's code. >> >> Or like programming in a post-GPT3 world where you're checking/fixing a >> transformer language model's plagiarized/regurgitated code. Our dystopian >> future. >> >> The site builds and runs your code. If your code doesn't compile or >> doesn't compute the correct function, the code is rejected. >> >> Each puzzle is a little program. Look at the example here: >> >> https://bugfix-66.com/contribute >> >> The code you edit on the website is under "// EDIT". Any code you put >> into the web form is compiled and run on the server. >> >> I'm relying on the fact that the Go language allows imports only at the >> start of the program text (immediately following the package statement). >> >> package xxx >> import yyy >> <... testing functions, etc., that I control ...> >> <code from website inserted here, so it can't import> >> >> Basically, the user can never write an import statement, and that's >> enough. >> >> Go doesn't allow inline assembly, so direct syscalls are impossible. All >> memory accesses are bounds checked. >> >> The code is built and executed with resource limits on memory and CPU >> time. >> >> If you can think of a way the server could be compromised, I'm VERY >> interested to hear it. Thank you. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/fd676e28-3639-4fc8-a7b4-3288e08fdd3en%40googlegroups.com >> >> <https://groups.google.com/d/msgid/golang-nuts/fd676e28-3639-4fc8-a7b4-3288e08fdd3en%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/cac42b40-e643-41e0-a143-7a9f0d2e2242n%40googlegroups.com.
