[16124] in Kerberos_V5_Development
Re: Profile access errors
daemon@ATHENA.MIT.EDU (Russ Allbery)
Mon Aug 23 18:06:39 2010
From: Russ Allbery <rra@stanford.edu>
To: "krbdev\@mit.edu" <krbdev@mit.edu>
In-Reply-To: <1282600494.8066.1319.camel@ray> (Greg Hudson's message of "Mon,
23 Aug 2010 17:54:54 -0400")
Date: Mon, 23 Aug 2010 15:06:35 -0700
Message-ID: <87vd71asr8.fsf@windlord.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
Greg Hudson <ghudson@MIT.EDU> writes:
> 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.
Unfortunately, the main thing that I'd want is the very hardest thing to
accomplish, namely some sort of error message stating which file couldn't
be opened and what the error was sent to somewhere where we'd see it. But
yes, that behavior matches what we saw (which was that the application
continued on oblivious, but then started throwing "cannot locate KDC for
default realm" error messages that confused things considerably).
If we had some sort of error message, we'd be able to figure it out,
almost no matter what the application then did. Without an error message,
it's really hard to figure out what's going on, even if the application
aborts, although if the application aborts strace would at least point us
more directly to the relevant error.
--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
