[20248] in Kerberos_V5_Development
Re: [RFC] Improvements to KCM prococol and notification mechanism
daemon@ATHENA.MIT.EDU (Greg Hudson)
Thu Feb 4 12:54:07 2021
To: =?UTF-8?Q?Pavel_B=c5=99ezina?= <pbrezina@redhat.com>, <krbdev@mit.edu>
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <c89ccc6e-e4d5-766e-1470-13c43128e0f3@mit.edu>
Date: Thu, 4 Feb 2021 12:53:44 -0500
MIME-Version: 1.0
In-Reply-To: <0744b0cb-9a26-855a-5ff0-5585ada84780@redhat.com>
Content-Language: en-US
Cc: Nico Williams <nico@cryptonector.com>
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
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.
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.
(MEMORY also can't satisfy the interface, but as long as it can return
an error that's probably not a problem.)
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
