nsenter: check cmdline for init argument #4342
Conversation
kolyshkin
changed the title
kolyshkin
changed the title
Fixes the failure when _LIBCONTAINER_INITPIPE is present in runc environment. Fixes: 4340. Signed-off-by: Kir Kolyshkin <[email protected]>
|
Yeah, this is better than resurrecting the |
There was a problem hiding this comment.
Is there a reason we care about this? I'd like to know, as maybe some suggestions don't improve that particular use case.
The cmdline parsing, if we can expect runc init to have more params in some setups, can mean to re-implement the parsing in C (up to some point). So it doesn't seem ideal if more params can be expected. Can they?
Another option would be to get the parent pid and check it is runc. But parsing /proc/self/status, get the ppid, check if the parent is runc in C is not nice. And... how to check it is runc? a md5sum of /proc/ppid/exec is expensive, the comm name can be fake also, so in the end it seems like the same problem we have today.
Another option might be to have an open fd on the parent, that we inherit when forking and checking that fd is open?
EDIT: cyphar said it doesn't take any comand-line options. So this PR seems like a good fix for me IF we want to fix this. Sorry for the noise :)
|
I'm also not really convinced this is worth fixing either. Ideally, we would only run the C code for That being said, |
|
In theory, we can also switch to passing fds and other stuff via cmdline, not sure what are the pros and cons of doing that vs passing via environment. Probably not worth changing. |
|
I'm not sure either if we should fix this. Arguments for:
Arguments against:
To me, both pros and contras are rather weak. |
|
I think moving
Somewhat related: We can fix this using |
Fixes the failure when
_LIBCONTAINER_INITPIPEis present in runc environment.Fixes: #4340.
Alternative to #4339.