From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 98FBDC43381 for ; Wed, 20 Mar 2019 15:03:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5D84C2146E for ; Wed, 20 Mar 2019 15:03:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Qo+LDk0+" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728279AbfCTPDI (ORCPT ); Wed, 20 Mar 2019 11:03:08 -0400 Received: from mail-yw1-f67.google.com ([209.85.161.67]:44020 "EHLO mail-yw1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726123AbfCTPDI (ORCPT ); Wed, 20 Mar 2019 11:03:08 -0400 Received: by mail-yw1-f67.google.com with SMTP id j66so2209399ywc.10 for ; Wed, 20 Mar 2019 08:03:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1rjEE0vnKicrSuNDq5IEa/M9T6SXKFsQ31cqgJABZsU=; b=Qo+LDk0+0c7udtSP46qc+MJf2gIvZh7Y4DpCAhLHzAF1woegedJBy4VWMFsvhItMBq QcHWqD1nhxYkvjUpdKpgZ9K0MqdAmLeHvclGWyhPO2E9N73xRI0vcbAHHnkzw+wuCDF6 yyiYAuebc6NiTW/riqTpOYcZT7aVSy7nAwAF/MnNuhR/Gm0mYIjFilmam+IwALwvVEjf va8B+B7MMzgg5dQLFFw//hVsfW99sy1/ut08TyzY5hxaMozUuT4WqOMCvWqXOEI91XCL NkGBJVxAJCZlGbH89Bn4GcU+zPQOIpC9YG8penw3rOqVnNAVhd/Ym0W8qGp6whCyIT2L AnAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1rjEE0vnKicrSuNDq5IEa/M9T6SXKFsQ31cqgJABZsU=; b=qYls6PHVWDv/HzspoYlirbJTAuDKWzSXVfx3JqfpprxOi+I25JLDPMu9804oqCg8lU FW6ZCFgQYraWz/OUIaTBafEuGQhx7xVIZEabUKXPb7P5Sbiq4agQHnV6DX9d660lRcCj eOGJT3pfVUOJ9tjkafToWzTeMbDSrcdRNXOrGpfByg75uKeMAos6SEIpLU5YzzxkdB7n Onp7yWA8LAS3/KUEUh5pGXBQL/+OzuCdqhTERH190P9FS/V1MdmNkwGEc3Fs8gH6ejb9 ZzNc+2id1qIZnKEG5cQ06pTVzHLC7XUhGNxdRAkDFWXoxn/W1pbRe5HguVsqCp40lU2B PUbA== X-Gm-Message-State: APjAAAWNHFWTGeKdSzzAoUceQgdKlt45nKuNPtlyWrQFuH1ke56xauOc IsWcHz8JOrsxQjTmXdwGZ8mcbUMwFnzQyOJrsEY= X-Google-Smtp-Source: APXvYqxL+R5o4Cbgung3yYm+iOtq1GbJeb1UTD6n/2qy4AcIYE7hYPmwnSFquGoQieI08+wiDKUErn00HC9Lth47/9w= X-Received: by 2002:a5b:c05:: with SMTP id f5mr7558232ybq.337.1553094187157; Wed, 20 Mar 2019 08:03:07 -0700 (PDT) MIME-Version: 1.0 References: <20190320131642.GE9485@quack2.suse.cz> <20190320143048.GH9485@quack2.suse.cz> In-Reply-To: <20190320143048.GH9485@quack2.suse.cz> From: Amir Goldstein Date: Wed, 20 Mar 2019 17:02:54 +0200 Message-ID: Subject: Re: fanotify permission events on virtual filesystem To: Jan Kara Cc: linux-fsdevel , mhocko@suse.cz, Al Viro , Marko Rauhamaa Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Wed, Mar 20, 2019 at 4:30 PM Jan Kara wrote: > > On Wed 20-03-19 15:46:20, Amir Goldstein wrote: > > On Wed, Mar 20, 2019 at 3:16 PM Jan Kara wrote: > > > recently, one of our customers has reported a deadlock with fanotify. The > > > analysis has shown that a process has put (likely by mistake) FAN_OPEN_PERM > > > mark on /proc and / filesystem. That resulted in a deadlock like follows: > > > > > > process 1: process 2: process 3: > > > open("/proc/process 2/maps") > > > - blocks waiting for response to > > > FAN_OPEN_PERM event > > > > > > exec(2) > > > __do_execve_file() > > > - grabs current->signal->cred_guard_mutex > > > do_open_execat() > > > - blocks waiting for response to > > > FAN_OPEN_PERM event > > > > > > reads fanotify event > > > generated by process 1 > > > create_fd() > > > dentry_open() > > > proc_maps_open() > > > blocks on > > > cred_guard_mutex of process 2. > > > > > > Now this is not the only case where you can setup fanotify permissions > > > events so that your listener deadlocks but I'd argue that this case is > > > especially nasty and it is unrealistic to expect from userspace that it > > > would be able to implement fanotify listener in such a way that is > > > deadlock-free for proc filesystem since the lock dependencies there are > > > very different. So how about we just forbid placing marks with fanotify > > > permission events on proc? Any other virtual filesystem we should exclude? > > > > > > > I bet if we forbid placing marks on /proc, some apps would break. > > Well, I didn't mean all marks, just the permission ones. I'm not sure there > are apps that place permission events on /proc... > Maybe not intentionally. I once tested a few fanotify based AntiVirus solutions. In some of them, setting an "Exclude path" on some mount point would cause mark to not be set on that path, but for one in particular, the mark was still being set on the mount so path pattern filtering was done after receiving the events. I did not check whether /proc was blacklisted out of the box or if it could be marked/excluded from scan. IMO, assuming that all AntiVirus vendors blacklist all virtual filesystems is an assumption that we need to validate. [CC Marko from F-Secure for commenting on the above.] > > I always though that allowing O_PATH in event_f_flags can make > > sense for some apps. > > > > What if instead of forbiding marks of /proc, we would force those > > marks to use O_PATH for fd creation. Some of the functionality > > will remain. Apps are less likely to break. Deadlocks will be less > > likely, although maybe still possible. > > Yes, that's another option. But if this is automatic, it is going to be > confusing to potential users - report O_PATH fd if getting normal fd is > dangerous isn't great. And also the deadlocks are there only for permission > events so there's no strong reason to restrict normal ones. > Of course, we can do this hack only for reading permission events for virtual filesystems. The question is what would be more surprising to existing apps: - marks for permission events no longer working on /proc - fd from permission events no longer readable from /proc - something completely different Thanks, Amir.