Re: NFS-Mount with MIT-Kerberos5 doesn't use user tickets...

[Chuck Lever <chuck.lever@oracle.com>]

On 04/09/2010 10:50 AM, Kevin Coffman wrote:
> On Fri, Apr 9, 2010 at 5:15 AM, Thomas Wunder
> <thomas.wunder@swt-bamberg.de>  wrote:
>> On Thursday 08 April 2010 20:58:49 you wrote:
>>> Sorry, I missed that, or forgot.  And you still get "mount : only root
>>> can mount ..." if you do "mount /mnt/net" as tomkrb ??  If so, that
>>> seems like a bug.
>>
>> No, with that entry each user is able to invoke mount. The problem is that
>> mount is carried out with uid=0 then.
>>
>>> Yes, because under sudo, you are running as root.
>> obviously...
>>
>> I'm wondering if there's a chance to run mount with a non-root uid at all. On
>> the other hand is that really needed? I mean I just want it to pass the
>> calling user's uid to the rpc.gssd...
>>
>> By the way the rpcsec_gss_krb5 is loaded.
>>
>>>   You said you had this working for the case where root did the mount
>>> using a keytab though, correct?  It can also be caused by a mismatch
>>> of sec flavors.  (i.e., is the server exporting with krb5p?)
>> Yes, it worked fine when i used a keytab-file with the key for the client-
>> machine-principal in it. When i issued mount everything worked fine. The
>> problem with this kind of setup is just that this would simply be some kind of
>> host-based authentication and I can't trust the people which will use the
>> clients as much to use a keytab file. They could simply boot from a LiveCD,
>> memstick etc. and steal that keytab file...
>> I've double checked that krb5p is specified in the server's /etc/exports as
>> well as in the client's /etc/fstab (i've also tried it with "krb5" on both
>> sides but that didn't make any difference) .
>>
>> Does it matter whether those two flags match before the security context is
>> completely established at all?
>
> I tried a user mount yesterday and it worked fine, but I had a keytab
> on the machine.  Looking closer today, I see two upcalls coming up for
> the user-mount case.  The first has uid 0, as you say.  The second was
> with my uid.  Removing my keytab causes the mount to fail as you are
> seeing.  Sorry to take so long to figure that out.
>
> I don't think this has always been the case.  Something might have
> changed with the new kernel mount code?
>
> Copying Chuck to see if he knows more...

I don't know anything about these upcalls, sorry.

-- 
chuck[dot]lever[at]oracle[dot]com