Re: [RFC] Improvements to KCM prococol and notification mechanism

Simo Sorce <[email protected]> Thu, 04 Feb 2021 13:14:23 -0500
Newsgroups gmane.comp.encryption.kerberos.devel
Organization Red Hat, Inc.
Message-ID <[email protected]>
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             [email protected]
https://mailman.mit.edu/mailman/listinfo/krbdev