fupan.lfp c1b6838e25 rustjail: refactoring the way of creating container process ...

In the previous implementation, create a container process
by forking the parent process as the container process,
and then at the forked child process do much more setting,
such as rootfs mounting, drop capabilities and so on, at
last exec the container entry cmd to switch into container
process.

But since the parent is a muti thread process, which would
cause a dead lock in the forked child. For example, if one
of the parent process's thread do some malloc operation, which
would take a mutex lock, and at the same time, the parent forked
a child process, since the mutex lock status would be inherited
by the child process but there's no chance to release the lock
in the child since the child process only has a single thread
which would meet a dead lock if it would do some malloc operation.

Thus, the new implementation would do exec directly after forked
and then do the setting in the exec process. Of course, this requred
a data communication between parent and child since the child cannot
depends on the shared memory by fork way.

Fixes: #166
Fixes: #133

Signed-off-by: fupan.lfp <fupan.lfp@antfin.com>

2020-03-23 17:12:10 +08:00

..

src

rustjail: refactoring the way of creating container process

2020-03-23 17:12:10 +08:00

Cargo.toml

path-absolutize: version update

2020-03-03 09:24:13 +08:00