[Freeipa-users] apache kerberized nfs4 /var/www/html access denied for apache user

Dmitri Pal dpal at redhat.com
Mon Sep 22 19:09:42 UTC 2014


On 09/20/2014 05:19 PM, Simo Sorce wrote:
> On Sat, 20 Sep 2014 19:44:28 +0200
> Rob Verduijn <rob.verduijn at gmail.com> wrote:
>
>> Hi again,
>>
>> Thank you for the quick response.
>> I've removed the credstore entries that are not necessary for the nfs
>> access.
>> Now the users no longer go through gssproxy, but apache does.
>>
>> I've googled around quite a bit and and it seems that your
>> presentation on youtube and the gssproxy page together with a bit on
>> the fedora site are about it concerning documentation.
> We do not have a lot of docs yet, indeed.


Is there any chance we can publish this setup somewhere as a HOWTO?
May be on GSS proxy or IPA wiki?
That would help others coming after you.

If you have a fedora account you can add content to FreeIPA wiki.


>
>> The below gssproxy.conf works fine for apache accessing  a kerberized
>> nfs share without having to authenticate against ipa.
>>
>> If I were to create another share for say an tftp directory do I need
>> to create another entry like the one below or can I simply say :
>> euid =  48,1,2,3,4
> Nope, euid is singlevalued.


Should we open RFE for it?
ding-libs can return you a list of numbers.

>
>> Or maybe this if you won't mind that any service with a keytab gets
>> nfs access.
>> euid = %U
> Setting %U in euid does not work, that's why we have allow_any_uid.
>
>> Thanx for the quick help.
> Glad you got it working to your liking, and feel free to ask questions
> directly on the gss-proxy mailing list if you want.
>
> Btw in the conf below you can also remove completely the allow_any_uid
> (no is the default) and the trusted options (you should not really
> trust apache to impersonate any user, w/o trusted it will just be
> itself).
>
> Simo.
>
>> [gssproxy]
>>
>> [service/nfs-client]
>>    mechs = krb5
>>    cred_store = client_keytab:/etc/gssproxy/%U.keytab
>>    cred_usage = initiate
>>    allow_any_uid = no
>>    trusted = yes
>>    euid = 48
>>
>>
>>
>> 2014-09-20 18:15 GMT+02:00 Simo Sorce <simo at redhat.com>:
>>
>>> On Sat, 20 Sep 2014 16:53:48 +0200
>>> Rob Verduijn <rob.verduijn at gmail.com> wrote:
>>>
>>>> Hello all,
>>>>
>>>> I've managed to get the gssproxy to work on my installation.
>>>> I can now mount my apache document root using sec=krb5p and apache
>>>> automagically mounts the share when needed.
>>>>
>>>> However I noticed that now all nfs credentials are going through
>>>> gssproxy. Is there a way to disable this for regular users (or
>>>> only enable it for apache)
>>>>
>>>> Below is the gssproxy.conf I used
>>> I assume you mean that gssproxy is used for all users when rpc.gssd
>>> is used ? You cannot pick and choose this way, but gss-proxy can be
>>> configured to user regular user's caches so that it preserve proper
>>> authorization for access.
>>>
>>>> Cheers
>>>> Rob
>>>>
>>>>
>>>>
>>>> [gssproxy]
>>>>
>>>> [service/nfs-client]
>>>>    mechs = krb5
>>>>    cred_store = keytab:/etc/krb5.keytab
>>>>    cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U
>>>>    cred_store = client_keytab:/etc/gssproxy/%U.keytab
>>>>    cred_usage = initiate
>>>>    allow_any_uid = yes
>>>>    trusted = yes
>>>>    euid = 0
>>> You do not need allow_any_uid in your case as rpc.gssd always runs
>>> as root.
>>>
>>> You can also remove the keytab:/etc/krb5.keytab option as you are
>>> only going to initiate with explicit client keytabs.
>>>
>>> If you only have the apache keytab in /etc/gssproxy then for any
>>> other user will fall back to local resolution.
>>>
>>> You may also experiment with setting ccache to the default for your
>>> system so that gss-proxy can find actual user's ccaches, though that
>>> may comport some minor risk and will force you to run gss-proxy as
>>> root.
>>>
>>>
>>> HTH,
>>> Simo.
>>>
>>>
>>> --
>>> Simo Sorce * Red Hat, Inc * New York
>>>
>
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.




More information about the Freeipa-users mailing list