On Sat, Oct 24, 2015 at 3:28 PM, Petko Manolov <[email protected]> wrote: > On 15-10-23 20:13:41, Dmitry Kasatkin wrote: >> On Fri, Oct 23, 2015 at 3:29 PM, Petko Manolov <[email protected]> wrote: >> > >> > I was actually going to get rid of IMA_FS_BUSY. It is less flexible with >> > respect to user-space tools. If the flag is up then the policy upload will >> > fail. The user script or program must check the error and repeat the >> > operation after some time. Seems kind of pointless to me, unless i am >> > missing something. >> > >> > With a semaphore the second process will block and write the policy once >> > the >> > first writer leave the operation. No need to repeat it unless there's some >> > real error. >> > >> > I was trying to be careful and not break the code in case the new >> > functionality is not selected in Kconfig. However, with your most recent >> > patch-set i guess we'll have to revisit a few things. :) >> >> Obviously in original situation it will be only a "single" policy writer - >> which IMA init script or binary. If some other script tries to write policy >> at >> the same time I would consider it as someone exploit would trying to do nasty >> things. > > You've got a point here. If we get rid of the busy flag we'll have to block > at > open() instead of write() in order to keep the "original" semantics. >
No, that was not my point. The point was that there is no another/simultaneous policy writer in reality. >> With possibility to update policy I also do not see any need for multiple >> writers, when second waits first to finish update and it is not aware about >> coming another update. It would be some integrity manager doing policy >> updates >> sequentially from time to time. > > Nope, that's not the only scenario. Imagine a machine with multiple tenants > and > huge uptime. Imagine also that these tenants want to run their own software > on > this machine. Policy write may occur at any time. > No, I cannot imagine that unrelated processes can write/update policy simultaneously at any time. I can imagine that some device/system management software does policy update. May be you could give more exact use case. >> But with "reading" the policy file, I could imaging process blocking to wait >> when update/read completes. > > We don't need mutexes to safely read the policy. The code that does list > splicing is taking care of the reader either seeing the original policy or the > new one. Not a disjointed version of it. > > Whether one will see the old or the new policy is a matter of timing and > semaphores are not going to change this. > Indeed. > > Petko -- Thanks, Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
