[32861] in Kerberos
Re: krb5_kuserok and unreadable .k5login files
daemon@ATHENA.MIT.EDU (Greg Hudson)
Sun Nov 7 11:36:47 2010
From: Greg Hudson <ghudson@mit.edu>
To: Geoffrey Thomas <geofft@mit.edu>
In-Reply-To: <alpine.DEB.1.10.1011062123190.26933@dr-wily.mit.edu>
Date: Sun, 07 Nov 2010 11:36:38 -0500
Message-ID: <1289147798.2633.1032.camel@ray>
Mime-Version: 1.0
Cc: "scripts-team@mit.edu" <scripts-team@mit.edu>,
Alexander Chernyakhovsky <achernya@mit.edu>,
"kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On Sat, 2010-11-06 at 22:06 -0400, Geoffrey Thomas wrote:
> There are also some cases where the file can exist but access() still
> returns nonzero; one in particular is EACCES. It's not clear to me if,
> say, POSIX allows that for F_OK
It can happen if you don't have search permission on one of the
directories leading to the file--that is, you're not allowed to know
whether the file exists or not.
> We're thinking that the best solution may be a fourth return code from
> k5login_ok, "UNUSABLE", in addition to ACCEPT/PASS/REJECT, to indicate
> that a .k5login exists but is unreadable or otherwise unusable to make
> security policy decisions. By default UNUSABLE would work like REJECT but
> instead callers of krb5_kuserok could use it to log a much clearer error
> asking you to investigate the permissions around the .k5login, but perhaps
> an option in krb5.conf could allow UNUSABLE to work like PASS.
I'd rather not add complexity to the accumulator.
I would be amenable to revving the API (that is, creating a new
function) so that it returns a krb5_error_code instead of a boolean.
Combined with extended error messages, this would allow for better logs.
> Another solution would be simply to explicitly consider the case of a
> .k5login being unreadable as the .k5login essentially not existing, and
> return PASS instead.
The default behavior assumes that if .k5login exists, it supercedes the
an2ln check. Given that policy, I think it would be dangerous to
restore the an2ln check in situations where we know the file exists but
can't read it.
We did add an option in 1.9 to make .k5login files non-authoritative
whether or not they can be read.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
