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.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 D7E3FC43331 for ; Thu, 5 Sep 2019 18:33:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DC15C20825 for ; Thu, 5 Sep 2019 18:33:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391294AbfIESd0 (ORCPT ); Thu, 5 Sep 2019 14:33:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33828 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391293AbfIESdT (ORCPT ); Thu, 5 Sep 2019 14:33:19 -0400 Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BB8F57CBB1 for ; Thu, 5 Sep 2019 18:33:18 +0000 (UTC) Received: by mail-wr1-f70.google.com with SMTP id s5so1358676wrv.23 for ; Thu, 05 Sep 2019 11:33:18 -0700 (PDT) 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=JkgFvZx1SpfRB54bm11+3DOumUuDokZW525XdQCPb+E=; b=jM+vDQf7BbR/e7yxHdUfREl95QkW0PIBvmWnpi7X1Y0Bk6vSqiB8ULBD/AwTFmOuC8 Yjnwnpp01F38IzRY7PLokM8EdF2szN7NuuiJcrKGY9WVCsL1IRtveby9oB+98izCsc9S khRlina7vHmn4DnS4/Q7crJobp1LfBXeMKtBg3CQT8LNgTl4POnjfVZLtENBAu0Dg9Pi n5mucRZdgr87gWwJyLkRgl6JAWcbyNq6G3t4Q9mqwz8yGgEmC2j/8qqwE9LjYBXpQ4yb uxYi0Onh4btDf7VQqHM3P4UYLaIA0OIBRkqRGtAOj1gTyu0S5kaeyALdHrcTa6y5seh9 49Nw== X-Gm-Message-State: APjAAAVlsFaA8WnZ2h4kyVRBkSPTBpgSrF9RBWClKn8I7/HQQwr53dR6 uSrVahVpbIseNww9jYaWs9tLlv76uAmy9vTeDcbmBxOMH05cYGRVqDrcJkvgyA5MaKgjQHKr/uu 4QRwBN2bHYwxTXNBtCAk8b7QChZWM1P1OAq68WD3HlNGa2ws3DAer X-Received: by 2002:a5d:568c:: with SMTP id f12mr3942172wrv.248.1567708397319; Thu, 05 Sep 2019 11:33:17 -0700 (PDT) X-Google-Smtp-Source: APXvYqzmOECwYwtvafDfOc5sH/mM1xRRq5odIdcrX+xDOVM3wNnjyolmP+riNwHwlSKTnHua2vRyqquS9BP4i+1k7Ig= X-Received: by 2002:a5d:568c:: with SMTP id f12mr3942141wrv.248.1567708396973; Thu, 05 Sep 2019 11:33:16 -0700 (PDT) MIME-Version: 1.0 References: <156763534546.18676.3530557439501101639.stgit@warthog.procyon.org.uk> <17703.1567702907@warthog.procyon.org.uk> In-Reply-To: From: Ray Strode Date: Thu, 5 Sep 2019 14:32:40 -0400 Message-ID: Subject: Re: Why add the general notification queue and its sources To: Linus Torvalds Cc: David Howells , Greg Kroah-Hartman , Steven Whitehouse , Nicolas Dichtel , raven@themaw.net, keyrings@vger.kernel.org, linux-usb@vger.kernel.org, linux-block , Christian Brauner , LSM List , linux-fsdevel , Linux API , Linux List Kernel Mailing , Al Viro , "Ray, Debarshi" , Robbie Harwood Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: Hi, On Thu, Sep 5, 2019 at 1:20 PM Linus Torvalds wrote: > You've at least now answered part of the "Why", but you didn't > actually answer the whole "another developer" part. It's certainly something we've wanted in the GNOME world for a long time: See for instance https://bugzilla.redhat.com/show_bug.cgi?id=991110 and https://bugzilla.gnome.org/show_bug.cgi?id=707402 from all the way back 2013. These are the alternatives I can think of: - poll? status quo, but not great for obvious wakeup reasons - use a different credential cache collection type that does support change notification? some of the other types do support change notification, but have their own set of problems. But maybe we should just go back to DIR type credential cache collections and try to figure out the life cycle problems they pose, i don't know... or get more man power behind KCM... - manage change notification entirely from userspace. assume credentials will always be put in place from krb5-libs entry points, and just skip notification if it happens out from under the libraries. maybe upstream kerberos guys would be onboard with this, I don't know. This seems less robust than having the kernel in the loop, though. > I really don't like how nobody else than you seems to even look at any > of the key handling patches. Because nobody else seems to care. I've got no insight here, so i'll just throw a dart... viro, is this something you have any interest in watching closer? > See what I'm saying? This whole "David Howells does his own features > that nobody else uses" needs to stop. You need to have a champion. I > just don't feel safe pulling these kinds of changes from you, because > I get the feeling that ABSOLUTELY NOBODY ELSE ever really looked at it > or really cared. I get the "one man is not enough for proper maintenance" argument, and maybe it's true. I don't know. But I just want to point out, I have been asking dhowells for this change notification API for years, so it's not something he did on his own and for no particularly good reason. It solves a real problem and has a real-world use case. He kindly did it because I (and Robbie Harwood and others) asked him about it, off and on, and he was able to fit it onto his priority list for us. >From this thread, it sounds like he solved a problem for Greg too, killing a couple birds with one stone? --Ray