Re: [Pki-devel] [PATCH] 46 Prevent concurrent execution of pkispawn and pkidestroy
On Wed, 2013-04-03 at 10:36 -0400, Abhishek Koneru wrote:
Hi Ade,
Please share your views on this. It is regarding a ticket to prevent a concurrent execution of pkispawn/pkidestroy.
On Tue, 2013-04-02 at 15:52 -0500, Endi Sukma Dewata wrote: On 4/2/2013 11:54 AM, Abhishek Koneru wrote:
Please review the patch which adds a locking mechanism to prevent pkispawn and pkidestroy to execute concurrently.
Some comments:
1. This mechanism locks the entire system, so only one pkispawn/pkidestroy can run at any time. Is this the intended behavior? Or should we lock a particular instance only?
I think it was decided to allow only one pkispawn/pkidestroy for an entire system.
pkispawn and pkidestroy do selinux operations. Only one set of selinux operations should be done at a time. Not doing this could cause an operation to fail or worse. If you like, you could try to lock this section only, but then you still need to ensure that concurrent oerations do not affect the same data -- for instance, are they touching the same ports? The simplest and easiest solution will be to lock to having one operation per system at a time.
2. If another script is already running, the current script will block until the other script is done. Is this the intended behavior? Or should it fail immediately? Or should it wait but show a message saying another script is running?
Since only the section of code which does spawn()/destroy() are under lock, all the user details are taken by that time. But the blocked script will be waiting for some-time. I think showing a message would be nice as Endi reviewed.
My first thought was that it should fail immediately. But I could see having it wait with the relevant message. The user can then choose to control-C if they want.
3. Right now the lock file is called /tmp/pkioperationlock.lck. It might be better to move it into /var/run/pki/pki-deployment.lock or something like that.
Will be changed.
PFA the patch for you convenience.
--Abhishek
On 4/3/2013 9:52 AM, Ade Lee wrote:
On Wed, 2013-04-03 at 10:36 -0400, Abhishek Koneru wrote:
1. This mechanism locks the entire system, so only one pkispawn/pkidestroy can run at any time. Is this the intended behavior? Or should we lock a particular instance only?
I think it was decided to allow only one pkispawn/pkidestroy for an entire system.
pkispawn and pkidestroy do selinux operations. Only one set of selinux operations should be done at a time. Not doing this could cause an operation to fail or worse. If you like, you could try to lock this section only, but then you still need to ensure that concurrent oerations do not affect the same data -- for instance, are they touching the same ports?
The simplest and easiest solution will be to lock to having one operation per system at a time.
Is it because the selinux operations in general are not safe to run concurrently? If that's the case what about selinux operations executed by other applications, do we need to be concerned about that? Or is this only a concern when the operations affect the same data (e.g. same instance/ports)? This means running concurrent pkispawn to create two unrelated instances with completely different settings should not be blocked at all. If that's the case, there are two things that can be done: 1. Lock the instance to make sure it's not modified at the same time. 2. Check to make sure different instances don't use conflicting settings (e.g. ports). In general we should be able to assume that people won't use conflicting settings in different instances. But if that happens the above steps should catch that. Does setup-ds.pl lock the entire system? Locking pkispawn/pkidestroy to prevent concurrent execution doesn't really prevent someone from using conflicting settings in a later execution. -- Endi S. Dewata
participants (2)
-
Ade Lee -
Endi Sukma Dewata