[16123] in Kerberos_V5_Development
Profile access errors (was Re: Profile include support)
daemon@ATHENA.MIT.EDU (Greg Hudson)
Mon Aug 23 17:54:57 2010
From: Greg Hudson <ghudson@mit.edu>
To: "rra@stanford.edu" <rra@stanford.edu>
In-Reply-To: <1282599468.8066.1310.camel@ray>
Date: Mon, 23 Aug 2010 17:54:54 -0400
Message-ID: <1282600494.8066.1319.camel@ray>
Mime-Version: 1.0
Cc: "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Mon, 2010-08-23 at 17:37 -0400, Greg Hudson wrote:
> That's probably a bug. profile_init() treats ENOENT, EACCESS, and EPERM
> as non-fatal errors, when it should probably only treat ENOENT as
> non-fatal. I'll fix that right now since it's a one-liner.
Actually, this is more complicated than I thought. There was a
deliberate change to make EACCESS (and later EPERM) non-fatal, with the
log message:
prof_init.c, prof_tree.c: Fixed calls to
profile_update_file/profile_open_file to handle the possibility
that we have lost permission to read one of the configuration
files in the file list (say it's in AFS). We should only fail
catastrophically if we can't read all of the files in the
profile.
If no profile file can be read, the code returns ENOENT, which is
ignored by init_os_ctx.c since libkrb5 can work in some environments
without any configuration.
A relatively non-controversial thing to do would be to make
profile_init() return EACCESS or EPERM if it saw one of those errors
when failing to read any profile file. I guess I'll do that for now. I
feel like the error-handling semantics here are very muddy, though; I'm
not at all convinced that the proper response to "I had an access error
reading one but not all configuration files" is to soldier on with the
ones you can read.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
