Difference between revisions of "User namespace"
Jump to navigation
Jump to search
| Line 2: | Line 2: | ||
* setup of memory descriptor (prctl syscall) (CAP_SYS_RESOURCE) (assigned to gorcunov@, discussion https://lkml.org/lkml/2014/8/4/570) | * setup of memory descriptor (prctl syscall) (CAP_SYS_RESOURCE) (assigned to gorcunov@, discussion https://lkml.org/lkml/2014/8/4/570) | ||
| − | * access to /proc/pid/map_files which we use for restore of shared memory (CAP_SYS_ADMIN) | + | * access to /proc/pid/map_files which we use for restore of shared memory (CAP_SYS_ADMIN) (assigned to avagin@. We are going to use memfd_create() for estoring shared memory) |
* using of SO_RCVBUFFORCE and SO_SNDBUFFORCE socket option (CAP_NET_ADMIN) | * using of SO_RCVBUFFORCE and SO_SNDBUFFORCE socket option (CAP_NET_ADMIN) | ||
* open_by_handle_at and linkat(AT_EMPTY_PATH) requires CAP_DAC_READ_SEARCH | * open_by_handle_at and linkat(AT_EMPTY_PATH) requires CAP_DAC_READ_SEARCH | ||
Revision as of 15:21, 13 October 2014
Implementing user namespace support in CRIU requires a few changes on kernel side. First of all when a new user namespace is created its capability get dropped off, thus any kernel aspect guarded with capable() may fail. In particular we found that the following things are not functional when we restore tasks running in own user namespace:
- setup of memory descriptor (prctl syscall) (CAP_SYS_RESOURCE) (assigned to gorcunov@, discussion https://lkml.org/lkml/2014/8/4/570)
- access to /proc/pid/map_files which we use for restore of shared memory (CAP_SYS_ADMIN) (assigned to avagin@. We are going to use memfd_create() for estoring shared memory)
- using of SO_RCVBUFFORCE and SO_SNDBUFFORCE socket option (CAP_NET_ADMIN)
- open_by_handle_at and linkat(AT_EMPTY_PATH) requires CAP_DAC_READ_SEARCH
- TIOCSLCKTRMIOS (CAP_SYS_ADMIN)
- mknod() requires CAP_MKNOD
The list will be updated with time. To resolve the problems we need to address every issue and modify the kernel. For first bullet there is a patch already floating around in kernel mailing list.