[16130] in Kerberos_V5_Development
Re: Profile include support
daemon@ATHENA.MIT.EDU (Nicolas Williams)
Mon Aug 23 18:41:39 2010
Date: Mon, 23 Aug 2010 17:39:34 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Russ Allbery <rra@stanford.edu>
Message-ID: <20100823223934.GW17097@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <87y6bx9d3u.fsf@windlord.stanford.edu>
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Mon, Aug 23, 2010 at 03:29:57PM -0700, Russ Allbery wrote:
> Ken Raeburn <raeburn@MIT.EDU> writes:
>
> > Russ is right, this should be fixed, whether as part of this project or
> > separately. But if krb5_init_context can fail because of a profile
> > library error, it becomes difficult to pass the error back to the
> > application, even with profile library API changes. If we can go
> > config-file-free (I forget, did that ever get fully implemented?), then
> > certainly the krb5_context can hold the profile library error info.
>
> It's incredibly ugly, I know, but if krb5_get_error_message(NULL, code)
> returned an appropriate error message after krb5_init_context failed, my
> existing code at least would happily retrieve it and report that error.
> You'd have to do something nasty with library globals in order to
> implement that, though.
Thread-specific data, not globals, but, yes.
But also, since libkrb5 supports zero-conf operation... returning an
error for EACCES while reading any but the default config file seems a
bit aggressive (particularly given the reason that EACCES now does not
result in an error).
Or maybe a krb5_get_profile_files(krb5_context context /* NULL OK */,
char **actual_files, char **missing_files, char **access_denied_files,
char **permission_denied_files).
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
