On 02-03-17 14:55, Brendan Kearney wrote: > On 03/02/2017 08:43 AM, Kees Bakker wrote: >> On 02-03-17 13:34, Brendan Kearney wrote: >>> On 03/02/2017 05:40 AM, Kees Bakker wrote: >>>> On 24-02-17 14:38, Brendan Kearney wrote: >>>>> On 02/24/2017 03:33 AM, Kees Bakker wrote: >>>>>> On 23-02-17 15:39, Brendan Kearney wrote: >>>>>>> On 02/23/2017 09:11 AM, Kees Bakker wrote: >>>>>>>> On 23-02-17 13:51, Brendan Kearney wrote: >>>>>>>>> On 02/23/2017 07:32 AM, Kees Bakker wrote: >>>>>>>>>> On 22-02-17 17:33, Brendan Kearney wrote: >>>>>>>>>>> On 02/22/2017 10:26 AM, Kees Bakker wrote: >>>>>>>>>>>> On 22-02-17 14:05, Brendan Kearney wrote: >>>>>>>>>>>>> On 02/22/2017 05:23 AM, Kees Bakker wrote: >>>>>>>>>>>>>> On 21-02-17 19:49, Brendan Kearney wrote: >>>>>>>>>>>>>>> On 02/21/2017 10:57 AM, Kees Bakker wrote: >>>>>>>>>>>>>>>> Hey, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Maybe one of the NFS users on this list could give me a hint >>>>>>>>>>>>>>>> what >>>>>>>>>>>>>>>> could be wrong. I'm not sure if it has any relation with >>>>>>>>>>>>>>>> FreeIPA/Kerberos. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I've set up an NFS server and I can mount the NFS directory on >>>>>>>>>>>>>>>> my client. So, I'm >>>>>>>>>>>>>>>> guessing that setting up Kerberos principal was done correctly. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> However, only root can actually access the mounted contents. >>>>>>>>>>>>>>>> Any other user >>>>>>>>>>>>>>>> only sees question marks as shown below. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The mount command is simple. >>>>>>>>>>>>>>>> $ sudo mount -v -t nfs srv1.example.com:/home /nfshome >>>>>>>>>>>>>>>> mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 >>>>>>>>>>>>>>>> mount.nfs: trying text-based options >>>>>>>>>>>>>>>> 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On the server side /etc/exports looks like this. >>>>>>>>>>>>>>>> /home *(rw,sync,sec=krb5i,no_subtree_check) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> $ sudo mount |grep nfs >>>>>>>>>>>>>>>> srv1.example.com:/home on /nfshome type nfs4 >>>>>>>>>>>>>>>> (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> $ sudo ls -ld /nfshome >>>>>>>>>>>>>>>> drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome >>>>>>>>>>>>>>>> $ sudo ls -l /nfshome >>>>>>>>>>>>>>>> total 0 >>>>>>>>>>>>>>>> drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> $ ls -l /nfshome >>>>>>>>>>>>>>>> ls: cannot access '/nfshome': Permission denied >>>>>>>>>>>>>>>> $ ls -l / | grep nfshome >>>>>>>>>>>>>>>> ls: cannot access '/nfshome': Permission denied >>>>>>>>>>>>>>>> d????????? ? ? ? ? ? nfshome >>>>>>>>>>>>>>>> >>>> [...] >>>> >>>> Continuing story... >>>> >>>> I've tried various things in the meantime. I've set up two test >>>> environments with virtual >>>> machines (virtualbox). >>>> * with Fedora 25; this works. >>>> * with Ubuntu 16.04; I'm getting the same problem (permission denied and >>>> question marks). >>>> >>>> I also looked at the verbose output of rpc.gssd, it gives >>>> >>>> ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE (Unspecified >>>> GSS failure. Minor code may provide more information) - Can't find client >>>> principal keesb@REALM in cache collection >>> does the actual error message say @REALM, or did you substitute that to >>> obscure sensitive info? if it does actually say @REALM, then you are >>> missing a config directive somewhere, that specifies the kerberos realm. >> Be assured that I'm using the real thing. >> >>>> getting credentials for client with uid 60001 for server srv1.example.com >>>> getting credentials for client with uid 60001 for server srv1.example.com >>>> WARNING: Failed to create krb5 context for user with uid 60001 for server >>>> srv1.example.com >> So rpc.gssd is trying to create a krb5 context. It succeeds for uid=0 but >> not for another >> user. >> >> [...] >> >> Log when the user is listing the directory >> Mar 2 14:24:00 clnt1 rpc.gssd[3612]: handling gssd upcall >> (/run/rpc_pipefs/nfs/clnt14) >> Mar 2 14:24:00 clnt1 rpc.gssd[3612]: handle_gssd_upcall: 'mech=krb5 >> uid=60001 enctypes=18,17,16,23,3,1,2 ' >> Mar 2 14:24:00 clnt1 rpc.gssd[3612]: handling krb5 upcall >> (/run/rpc_pipefs/nfs/clnt14) >> Mar 2 14:24:00 clnt1 rpc.gssd[3612]: process_krb5_upcall: service is >> '<null>' >> Mar 2 14:24:00 clnt1 rpc.gssd[3612]: ERROR: GSS-API: error in >> gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may >> provide more information) - Can't find client principal keesb@REALM in cache >> collection >> Mar 2 14:24:00 clnt1 rpc.gssd[3612]: getting credentials for client with >> uid 60001 for server srv1.example.com >> Mar 2 14:24:00 clnt1 rpc.gssd[3612]: CC '/tmp/krb5ccmachine_REALM' being >> considered, with preferred realm 'REALM' >> Mar 2 14:24:00 clnt1 rpc.gssd[3612]: CC '/tmp/krb5ccmachine_REALM' owned by >> 0, not 60001 >> Mar 2 14:24:00 clnt1 rpc.gssd[3612]: getting credentials for client with >> uid 60001 for server srv1.example.com >> Mar 2 14:24:00 clnt1 rpc.gssd[3612]: WARNING: Failed to create krb5 context >> for user with uid 60001 for server srv1.example.com >> Mar 2 14:24:00 clnt1 rpc.gssd[3612]: doing error downcall >> >> [...] > file a bug > > [brendan@desktop ~]$ ll /tmp/ > total 36 > -rw------- 1 brendan brendan 4111 Mar 2 08:22 krb5cc_1000_9GeQKj > -rw------- 1 root root 579 Mar 1 10:08 krb5ccmachine_BPK2.COM > > users should never have, and never be required to have, access to the > machines kerberos credential cache.
That is indeed the clue. On Ubuntu the credential cache is kept in the KEYRING. But gssd isn't looking for it. If I create a credential cache in /tmp like so $ KRB5CCNAME=/tmp/krb5cc_keesb kinit the access to the NFS now succeeds. Hurray :-) $ ls -l /nfshome/ total 0 drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb Is it a bug of gssd? I'm not sure. I think gssd has no keyring support at all. Fedora must do things differently, because there, it seems, the /tmp file is present. How is that file created? -- Kees -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
