Mailing List Archives
Authenticated access
|
|
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[HTCondor-users] condor_interactive & condor_ssh_to_job & /usr/libexec/condor/condor_ssh_to_job_shell_setup & PID namespaces
- Date: Thu, 28 Feb 2019 10:42:51 +0100
- From: Bert DeKnuydt <Bert.Deknuydt@xxxxxxxxxxxxxxxx>
- Subject: [HTCondor-users] condor_interactive & condor_ssh_to_job & /usr/libexec/condor/condor_ssh_to_job_shell_setup & PID namespaces
Hello all people Condorese,
1) There is still a thinko in /usr/libexec/condor/condor_ssh_to_job_shell_setup if
I understand things correctly.
*) There's a code snippet meant to kill the dummy sleep, killing whatever is in
_CONDOR_JOB_PIDS, when the job is 'Interactive'.
*) However, if I launch an Interactive job, and later, possibly much much later,
do a 'condor_ssh_to_job' to that Interactive Job, that code is ran again and
a process with _CONDOR_JOB_PIDS is killed. That process can be literally
anything, as pids can easily have rolled over by then.
This is obviously unintentional and can pose a risk to other processes.
(Luckily it all runs with the users credentials only).
*) That could be fixed by assuring that the target of the kill is indeed that
sleep; or alternatively by disallowing ssh_to_job to an interactive job.
(But that is really used here though). Or just leave the sleep to die by itself.
2) Apart from that, there's another inconsistency, when a startd runs with PID
isolation (i.e. : USE_PID_NAMESPACES = True); then neither ssh_to_job nor a plain
'Interactive Job' really run under the PID namespace; only the dummy sleep did.
In other words, for practical purposes, you should not allow ssh_to_job nor
interactive jobs, if you really need PID isolation.
Fixing this will change the whole thing about finding the target of that kill...
Greetings, Bert.