[20249] in Kerberos_V5_Development
Re: [RFC] Improvements to KCM prococol and notification mechanism
daemon@ATHENA.MIT.EDU (Simo Sorce)
Thu Feb 4 13:14:52 2021
Message-ID: <e486bd4ff11b156a4bfd8d4ab10dd6035b6f8bf0.camel@redhat.com>
From: Simo Sorce <simo@redhat.com>
To: Greg Hudson <ghudson@mit.edu>,
Pavel =?UTF-8?Q?B=C5=99ezina?=
<pbrezina@redhat.com>, krbdev@mit.edu
Date: Thu, 04 Feb 2021 13:14:23 -0500
In-Reply-To: <c89ccc6e-e4d5-766e-1470-13c43128e0f3@mit.edu>
MIME-Version: 1.0
Cc: Nico Williams <nico@cryptonector.com>
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Thu, 2021-02-04 at 12:53 -0500, Greg Hudson wrote:
> On 2/4/21 5:25 AM, Pavel Březina wrote:
> > The goal is to provide common interface that would yield a path on which
> > consumers can inotify, obviously other mechanisms could be use on other
> > platforms eg fswatch on Mac.
>
> I guess an application could always fall back to polling the file if the
> platform has no inotify equivalent. It would be cheaper than polling
> the ccache.
Indeed.
> But what path would the KEYRING type return? I took a look at the
> general notification mechanism in Linux 5.8 and it doesn't seem to go
> through the filesystem.
I think the keyring is fast enough that we can simply return an error
and client will fall back to polling.
> (MEMORY also can't satisfy the interface, but as long as it can return
> an error that's probably not a problem.)
We could return a memfd ... and then operations on a memory cache would
simply "touch" the memfd to trigger notifications, but an error will
also be fine for the time being, notifications on a memory ccache are
not terribly interesting...
Simo.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
