Hacker News new | comments | show | ask | jobs | submit login
Pastebin, compiler, and debugger supporting 40+ languages (ideone.com)
79 points by ujeezy on July 29, 2010 | hide | past | web | favorite | 35 comments

Obligatory cross-link to codepad: http://codepad.org/

Footnote to history: I liked codepad so much when I first saw it on HN back in 2008, I tracked down the guy who made it (Steve Hazel/sah) and made him my co-founder! :-)

You made Selenium, you're not too shabby yourself.

How does it feel to be the author of a goddamn resume requirement? :-P


:-) I'll celebrate when these two lines cross: http://www.indeed.com/jobtrends?q=qtp,+selenium

Until then, we've got work to do!

How does it feel to be the author of a goddamn resume requirement?

Now there's one for the bucket list...

ideone is better than codepad, but I like both of them

Guess they thought of that...


Maybe they're running the untrusted user-submitted code as processes under the 'nobody' user as a security measure.

I've built something similar for my upcoming programmer-testing service at http://codeboff.in and this is one of the precautions I've taken in my own sandboxing arrangement.

And no setuid executables either, at least not in the path.


They also guard their compilation environment (I think)


How is that paste an example of the compiler being guarded?

In fact it looks like '/etc/passwd' is readable to the compiler after all.

The Python example in parent printed an /etc/passwd full of nobody-accounts. From my error message, I only know that the first line in the compilation environment is a nobody-account. In all /etc/passwds I remember having dealt with (mostly the distribution-maintained ones of Linux distributions), the first line was the root account. This is by no means a proof that the compilation environment is guarded, but a strong hint.

OK, but I wonder if it's not easier to just block access to /etc/passwd from the compiler while it is compiling user-submitted code. AppArmor or SELinux could be used to do this.

A decoy /etc/passwd is a bit less plausible to me.

As for the plausibility of the decoy, how do you interpret the output of the Python interpreter in the great-grandparent comment?

If I had to build a compile-and-run sandbox, I'd also look into SELinux or AppArmor. However, blocking reads to /etc/passwd will disable getpwent(), which innocent programs may occasionally use, and with shadow passwords, /etc/passwd should not be sensitive anyway.

Hmm, I have to admit a 'nobody' account with UID and GID 0 is weird. I'm not sure if it is possible for a non-superuser to have those values so you may be right here.

With AppArmor, at least, it is perfectly possible to assign different policies to the same program. Policies are applied to programs identified by pathname so all one needs to do to sandbox, for instance, /usr/bin/gcc:

1. ln /usr/bin/gcc-4.4 ~/sandbox/compilers/gcc 2. Create and enforce an apparmor policy for ~/sandbox/compilers/gcc 3. Remember to use only ~/sandbox/compilers/gcc for untrusted code.

I do this (among other things) for my platform, and given that I only require user-submitted code to solve one of a limited set of algorithmic challenges, I can get away with blocking access to /etc/passwd (and everything else but a restricted whitelist).

Is running each code as a separate process really scalable?

They run a C++ compiler on user-supplied code. That should dominate context-switching overhead.

I built a Chrome extension that meets gist.github.com and ideone.com http://github.com/NV/run-this-gist. Alas, API doesn't work well in most cases http://ideone.com/tXexT.

Nice idea. There is also a GistDoIt: http://www.gistdoit.com/about

If I knew about it wouldn't build mine.

Why? The more options to choose, the better.

They have an API! http://ideone.com/api

I'd have to learn SOAP first, but I've been meaning to do a website similar to tryruby.com for one of my projects. This looks like it could definitely help.

Try http://run-this.appspot.com/ if you don't want to learn SOAP.

I wrote a Python wrapper that you can use without having to know SOAP: http://github.com/mkilling/ideone.py

Yesterday and today, I quickly wrote up a Ruby interface to the API: http://github.com/Pistos/ideone-gem

There are some examples to help you start.

I could see this useful for coding tests during interviews.

see[Mike]code might be an even better fit for that purpose:


You can always use any of online judge services allowing you to set problem/organize contests (like http://spoj.pl) but how do you know your candidate is really solving the problem by himself?

What is the advantage here?

You'd save the time needed to switch between environments if you want to examine the candidate in different languages.

Indeed, good point!

Interesting! you can use java-scripting api for running jruby, jpython etc on server but how're they doing it for C/C++?

A nice feature (compared to codepad) is the ability to specify input.

Right! You can specify even multiple inputs and clone them - helps while you need to modify/test a code snippet.

it is integrated with FB, nice!

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact