On 30.03.2016 20:47, Steve Grubb wrote: Hi, >> Now to the patch: This solution really looks half baked to me. What if >> there are two processes mediating the access? > > While this is certainly possible, is this actually done in real life? we actually DID do this. We did not use fanotify though, since this did not exist then, but dazukoFS a stackable filesystem which worked similar to fanotify. If you want to scan files e.g for viruses you want to have it done as fast as possible and multiple scanner (processes) is what you need then. > > >> You'll get the deadlock again: We have processes A and B mediating access. A >> accesses some file f, A selfapproves the event for itself but the access is >> still blocked on the approval from B. B proceeds to process the access >> request by A. It accesses some file which generates the permission event - >> now B is blocked waiting for A to approve its event. Dang. >> >> This really resembles a situation when e.g. multipathd must be damn carful >> not to generate any IO while it is running lest it deadlocks while >> reconfiguring paths. So here you have to be damn careful not to generate >> any events when processing fanotify permission events... And I know that is >> inconvenient but that's how things were designed and duck taping some >> special cases IMHO is not acceptable. > > The issue here is that any relatively interesting program will have several > libraries who could at any time decide it needs to open a file. Perhaps even > /etc/hosts for network name resolution. You really don't know what the third > party libraries might do and the consequences are pretty severe - deadlock. > > You could make it multi-threaded and have one thread dequeuing approval > requests and another servicing them. But...each request has a live descriptor > that counts towards the rlimit for max open descriptors. Hitting that is bad > also. > > The simplest solution is to assume that the daemon is going to approve its own > request. It would never refuse its own request, should it? > I have thought about this problem long ago when fanotify came out, because dazukoFS actually provided the possibility to set arbitrary processes to an "ignore" list exactly for this reason and I wondered how we would handle this with fanotify. But then I came to the result that all you need to do is make sure that you have one dedicated process which does nothing else than approving (or denying) file accesses. If that process knows the pid of the processes that handle the file accesses (in our case the file scanner processes) it could simply ack all accesses done by them (note that the pid of the file accessing process is part of an fanotify event). For all file accesses done by unknown pids it would have to wait for an ACK from the scanner processes. Sure, that would require quite some interprocess communication between scanner processes and the "approver process" but it should work. Regards, Lino -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
