[Freeipa-users] Can mount NFS, but user only gets the permission question marks

[Kees Bakker]

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 at 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 at 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 at 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