Is there any set of compiler parameters that can be used to prevent a C++ program from having any access to most system functions, leaving it with access to read/write to stdin/stdout, but otherwise unable to harm the system.

This strikes me as being useful for systems such as a homework submission server or an online "tryit" server.

  • I don't think this would be done by the compiler, but instead sandboxing could be used at runtime. Commented Apr 30, 2018 at 2:39
  • @multithr3at3d, well my assumption is that disabling all of the libraries that allow a program to access the system (e.g. file access) would allow the program to be effectively sandboxed at compile-time. Commented Apr 30, 2018 at 3:21

1 Answer 1


Providing such restrictions are usually not considered the task of a compiler and it would be very hard to do anyway. Even if only a restricted set of libraries would be available for linking it is still possible to directly call into syscalls, i.e. no library needed.

For the use case you envision (homework submission) one should instead execute the generated program inside some restricted environment, i.e. sandboxing it within a virtual machine, containers or similar. In the simplest case you might run the code as a different and restricted user but then you should be really sure that your system is not exploitable by a low privileged user.

But there is another interesting use case where the developer itself wants to restrict the abilities of the program in order to reduce the impact of possible bugs in the program. Here technologies like pledge, seccomp or similar allow the program to explicitly give up the ability to do specific system calls (which can never be gained again) so that a bug in the program cannot be used to cause much harm.

Using the last idea where the program restricts itself could be also used in your use case to enable such restrictions before main gets called. One might do this to have a different compiler runtime or have other ways to execute code before main. Personally I would have much less trust in such a solution since much more can go wrong compared to running inside a real sandbox.

See also this questions at Unix & Linux where the OP tries to solve a similar problem and where a solution using seccomp is described in detail.

  • Well, couldn't the usage of syscalls also be disabled (outside of, say, a single library which provided a restricted subset of IO)? Commented Apr 30, 2018 at 4:12
  • I'd rather not have to resort to using a VM, due to performance reasons (and also the overhead of needing to have hundreds of VMs), but seccomp looks interesting, if there's a way to force it into the program... Commented Apr 30, 2018 at 4:17
  • @StackTracer: see updated answer. Commented Apr 30, 2018 at 4:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .