I am working on hardening a sandbox for student code execution. I think I'm satisfied that students can't share data on the file system or with signals because I've found express rules dictating those and they execute as different unprivileged users. However, I am having a really hard time looking at documentation to determine, when shared memory (or IPC more generally - queues or semaphores) is created, who can see that. If you create shared memory, can anyone on the same machine open it, or is there a way to control that? Does the control lie in the program that creates the memory, or can the sysadmin limit it?
0
Add a comment |
1 Answer
Any process in the same ipc namespace can see and (potentially) access ipc objects created by other processes in the same ipc namespace. Each ipc object has the same user/group/other-rwx permissions as file system objects objects -- see the svipc(7) manual page.
You can create a new ipc namespace by using the clone(2) system call with the CLONE_NEWIPC flag. You can use the unshare(1) program to do a clone+exec of another program with this or certain other CLONE flags.
3 Comments
daveagp
If I am using fork() instead of clone(), do you think I can use unshare() instead with CLONE_NEWIPC? (What a great function name! Makes my question look kind of foolish in retrospect.)
Chris Dodd
Looks like
unshare just calls clone+exec with the appropriate flags, so it should do exactly what you want...daveagp
Yup it seems to do the trick. The manual warns "unshare() does not implement flags that reverse the effects of CLONE_SIGHAND, CLONE_THREAD, or CLONE_VM" but none of those seem to be relevant to my case. Thank you!