pam-krb5 3.6 released

Markus Moeller huaraz at moeller.plus.com
Wed Sep 19 18:42:28 EDT 2007


I have a case were an application uses pam calls to authenticate users 
(selected by a seperate pam.conf  line or pam.d/appl file). This application 
will be maintained by an application support group which generally does  not 
need root access and the application itself runs also as non root to avoid 
more serious system compromises.  To make sure that I the server talks to 
the right kdc I'd like to verify the ticket against a keytab. As you say 
your code supports different keytabs which is fine, but your verify call 
krb5_verify_init_creds uses NULL as principal which means it requires a 
host/fqdn principal in the keytab to which I don't want to give access to. 
I prefer to use another principal like app1/fqdn which can be managed by the 
application support team. To do so I need an option for pam_krb5 to select 
the principal or a way to set GSS_C_NO_NAME.

Is that an unusual case ?

Markus


"Russ Allbery" <rra at stanford.edu> wrote in message 
news:871wcuqvif.fsf at windlord.stanford.edu...
> "Markus Moeller" <huaraz at moeller.plus.com> writes:
>
>> Did you have a chance to look at the keytab verification problem I
>> mentioned some time ago ?  Right now you need to have a host/fqdn entry
>> to verify the tickets, but this means the application needs to run as
>> root (Assuming verify_ap_req_nofail is set to true which I think should
>> be the default for pam anyway)
>
> It doesn't need to run as root but it does need to have read access to
> some keytab.  That keytab can be anything you choose and there's already a
> configuration option for that.
>
> There is a request for some way of verifying tickets against a keytab that
> isn't readable by the user who is running the program that is doing ticket
> verification, which is useful in some specific limited situations on
> multi-user machines with xlock.  This, however, looks like it requires a
> setuid or setgid helper program and a Kerberos v5 authentication over a
> private socket, and I'm not really sure that I want to try to maintain
> that code.
>
> -- 
> Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
> 






More information about the Kerberos mailing list