Difference between revisions of "Labeled NFS/Demo/Manual"

From SELinux Wiki
Jump to: navigation, search
(New page: In general, the following order of installation should be followed. The NFS and LDAP installation steps could be reversed if desired. Kerberos should be configured prior to both the NFS an...)
 
m (Misc Notes/FAQ)
 
Line 28: Line 28:
  
 
= Misc Notes/FAQ =
 
= Misc Notes/FAQ =
 
Endless error messages on the client similar to:
 
 
<pre>
 
Jul 15 11:19:07 seclient rpc.gssd[1776]: ERROR: GSS-API: error in gss_acquire_cred(): Unspecified GSS failure.  Minor code may provide more information - No credentials cache found
 
Jul 15 11:19:07 seclient rpc.gssd[1776]: WARNING: Failed to create krb5 context for user with uid 42 for server sefos.selinuxnow.org
 
</pre>
 
* uid 42 is GDM on the machine.
 
* This doesn't stop Kerberos based logins using GDM, but it does fill up the logs and I have not been able to find a fix for it.
 
 
 
Notable from http://www.citi.umich.edu/projects/nfsv4/linux/faq/ :
 
Notable from http://www.citi.umich.edu/projects/nfsv4/linux/faq/ :
  

Latest revision as of 16:05, 12 December 2008

In general, the following order of installation should be followed. The NFS and LDAP installation steps could be reversed if desired. Kerberos should be configured prior to both the NFS and LDAP installation instructions below depend on Kerberos, particularly to test that they are working properly. The system configuration instructions depends on all three servers and should be completed last.


Helpful Links

Links that are helpful in setting up Kerberos, NFSv4, LDAP:

Misc Notes/FAQ

Notable from http://www.citi.umich.edu/projects/nfsv4/linux/faq/ :

  • I am accessing an NFSv4 mount via Kerberos as root. Why isn't it using the credentials I got via kinit?
    • ALL accesses as root on a Linux client (uid=0) currently use the machine credentials, not any credentials obtained via kinit. We plan to change this behavior when moving to use the new key ring kernel support to store credentials and contexts.
  • I am accessing an NFSv4 mount via Kerberos and then I do a kdestroy, but I am still able to access the NFS data. Why?
    • The kernel code caches the gssapi context that was negotiated using the Kerberos credentials. Destroying the credentials does not destroy the context in the kernel. We plan to change this behavior when moving to use the new key ring kernel support to store credentials and contexts.
  • I keep hearing about this key ring support, when will it be ready?
    • We're working on it! The plan is to have it working ASAP.