[16248] in Kerberos_V5_Development
Re: ANAME_DB re-enable with patch.
daemon@ATHENA.MIT.EDU (Nicolas Williams)
Thu Sep 2 19:52:17 2010
Date: Thu, 2 Sep 2010 18:51:57 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: "Roland C. Dowdeswell" <elric@imrryr.org>
Message-ID: <20100902235157.GV1198@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20100902232623.GD15284@mournblade.imrryr.org>
Cc: Sam Hartman <hartmans@mit.edu>, krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Fri, Sep 03, 2010 at 12:26:23AM +0100, Roland C. Dowdeswell wrote:
> LDAP, we should be a little careful about. Given that currently,
> krb5_kuserok() does not cause any network dependent services that
> can return transient failures and cannot block [for long] if you
> are running on a local file system, this could change the expectations
> of callers about how krb5_kuserok() actually works. This is not
> to say that it shouldn't be done---but there are gotchas in taking
> a function call that returns explicit and correct results and adding
> in a network backend such as LDAP without also changing the API to
> allow for transient failures to occur in a way that calling
> applications can understand and cope with.
Apps that call krb5_kuserok() typically call lots of functions that
block on network I/O. E.g., getpwnam(), PAM (when the PAM config
involves modules like pam_ldap), ...
There's always the risk of one more blocking call being one to break the
proverbial camel's back, but I'm not too concerned about that. Keep in
mind that I'm all for async APIs.
Nico
--
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
