Priya Govindarajan wrote: > Hi, > > I am trying to understand how gss_acquire_cred works. > > When trying gss_server and gss_client - sample programs : When > gss_server run as user root the gss_acquire_cred function executes without > any errors. (The service principal key is added to the keytab file) > > When I execute gss_server as another other user I get the following error > "server_acquire_creds: sample > server_acquire_creds: calling gss_acquire_credGSS-API error acquiring > credentials: Miscellaneous failure > GSS-API error acquiring credentials: Permission denied" > > My understanding is gss_acquire_cred tries to get the default credential > from credential cache.
No. With Kerberos gssapi, there are two types of credentials tickets in caches and keytabs. The gss_acquire_cred can be called with gss_cred_usage: GSS_C_INITIATE, GSS_C_ACCEPT or GSS_C_BOTH. This sort of maps to use a ticket cache with gss_init and use a use keytab for gss_accept (user-to-user is the exception.) But your problem is most likely that the server is trying to use the default keytab file that is readable only by root. If you have a user owned keytab, you could set KRB5_KTNAME to point at it. How does gss_server as user root is able to > execute gss_acquire_cred function without any cred in credential cache. It ues the keytab file for the machine. > What is problem when executing gss_server as anyother user ? > > Thanks, > Priya > ________________________________________________ > Kerberos mailing list [email protected] > https://mailman.mit.edu/mailman/listinfo/kerberos > > -- Douglas E. Engert <[EMAIL PROTECTED]> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
