[Freeipa-users] Permission Denied
Dmitri Pal
dpal at redhat.com
Thu Sep 12 02:25:43 UTC 2013
On 09/11/2013 10:10 PM, Dean Hunter wrote:
> On Wed, 2013-09-11 at 21:34 -0400, Dmitri Pal wrote:
>> On 09/11/2013 09:27 PM, Dean Hunter wrote:
>>> On Wed, 2013-09-11 at 21:10 -0400, Dmitri Pal wrote:
>>>> On 09/11/2013 08:49 PM, Dean Hunter wrote:
>>>>> On Wed, 2013-09-11 at 11:49 -0400, Simo Sorce wrote:
>>>>>> On Wed, 2013-09-11 at 10:39 -0500, Dean Hunter wrote:
>>>>>> > On Wed, 2013-09-11 at 11:20 -0400, Simo Sorce wrote:
>>>>>> > > On Wed, 2013-09-11 at 08:39 -0500, Dean Hunter wrote:
>>>>>> > >
>>>>>> > > > I do NOT believe this:
>>>>>> > > > [dean at ipa2 ~]$ ssh dean at desktop2
>>>>>> > > > Last login: Wed Sep 11 08:32:21 2013 from ipa2.hunter.org
>>>>>> > > > Could not chdir to home directory /home/net/dean: Permission
>>>>>> > > > denied
>>>>>> > > > -bash: /home/net/dean/.bash_profile: Permission denied
>>>>>> > > >
>>>>>> > > > -bash-4.2$ logout
>>>>>> > > > -bash: /home/net/dean/.bash_logout: Permission denied
>>>>>> > > > Connection to desktop2 closed.
>>>>>> > > >
>>>>>> > > > [dean at ipa2 ~]$ su -
>>>>>> > > > Password:
>>>>>> > > >
>>>>>> > > > [root at ipa2 ~]# ssh dean at desktop2
>>>>>> > > > dean at desktop2's password:
>>>>>> > > > Last login: Wed Sep 11 08:34:29 2013 from ipa2.hunter.org
>>>>>> > > >
>>>>>> > > > [dean at desktop2 ~]$ logout
>>>>>> > > > Connection to desktop2 closed.
>>>>>> > > >
>>>>>> > > > [root at ipa2 ~]# logout
>>>>>> > > >
>>>>>> > > > [dean at ipa2 ~]$ ssh dean at desktop2
>>>>>> > > > Last login: Wed Sep 11 08:35:16 2013 from ipa2.hunter.org
>>>>>> > > >
>>>>>> > > > [dean at desktop2 ~]$
>>>>>> > > >
>>>>>> > >
>>>>>> > > Are you using a kerberized NFS mount ?
>>>>>> > >
>>>>>> > > I think what is happening is that when going via SSH rpc.gssd cannot
>>>>>> > > find your ticket, ssh may be doing something "wrong" in this case.
>>>>>> > >
>>>>>> > > Simo.
>>>>>> > >
>>>>>> > Yes, I am using Kerberos with NFS.
>>>>>> >
>>>>>> > Should I report this as a bug?
>>>>>> >
>>>>>> We need to decide what component is faulty. It may be possible we can
>>>>>> get it working somehow.
>>>>>>
>>>>>> When you ssh in what is the ccache ssh assign you ?
>>>>>> can you run klist and post the output (sanitize it if needed) ?
>>>>>>
>>>>>> Simo.
>>>>>>
>>>>> I hope this is what you requested:
>>>>>
>>>>> [dean at ipa2 <mailto:dean at ipa2> ~]$ klist
>>>>> Ticket cache: DIR::/run/user/1387400001/krb5cc/tktFDDxRR
>>>>> Default principal: dean at HUNTER.ORG <mailto:dean at HUNTER.ORG>
>>>>>
>>>>> Valid starting Expires Service principal
>>>>> 09/11/13 19:43:28 09/12/13 19:43:28
>>>>> krbtgt/HUNTER.ORG at HUNTER.ORG <mailto:HUNTER.ORG at HUNTER.ORG>
>>>>>
>>>>> [dean at ipa2 <mailto:dean at ipa2> ~]$ ssh dean at desktop2
>>>>> <mailto:dean at desktop2>
>>>>> Last login: Wed Sep 11 19:41:48 2013 from ipa2.hunter.org
>>>>> Could not chdir to home directory /home/net/dean: Permission
>>>>> denied
>>>>> -bash: /home/net/dean/.bash_profile: Permission denied
>>>>>
>>>>> -bash-4.2$ hostname
>>>>> desktop2.hunter.org
>>>>>
>>>>> -bash-4.2$ klist
>>>>> klist: No credentials cache found (ticket cache
>>>>> FILE:/tmp/krb5cc_1387400001)
>>>>>
>>>>> -bash-4.2$ logout
>>>>> -bash: /home/net/dean/.bash_logout: Permission denied
>>>>> Connection to desktop2 closed.
>>>>>
>>>>> [dean at ipa2 <mailto:dean at ipa2> ~]$ klist
>>>>> Ticket cache: DIR::/run/user/1387400001/krb5cc/tktFDDxRR
>>>>> Default principal: dean at HUNTER.ORG <mailto:dean at HUNTER.ORG>
>>>>>
>>>>> Valid starting Expires Service principal
>>>>> 09/11/13 19:43:28 09/12/13 19:43:28
>>>>> krbtgt/HUNTER.ORG at HUNTER.ORG <mailto:HUNTER.ORG at HUNTER.ORG>
>>>>> 09/11/13 19:44:43 09/12/13 19:43:28
>>>>> host/desktop2.hunter.org at HUNTER.ORG
>>>>> <mailto:desktop2.hunter.org at HUNTER.ORG>
>>>>>
>>>>> [dean at ipa2 <mailto:dean at ipa2> ~]$
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Freeipa-users mailing list
>>>>> Freeipa-users at redhat.com <mailto:Freeipa-users at redhat.com>
>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>>> Do I get it right: you tried twice and the first time it did not
>>>> work while the second it did?
>>>> There might be a race condition mounting your home directory using
>>>> your ticket.
>>>>
>>>> --
>>>> Thank you,
>>>> Dmitri Pal
>>>>
>>>> Sr. Engineering Manager for IdM portfolio
>>>> Red Hat Inc.
>>>>
>>>>
>>>> -------------------------------
>>>> Looking to carve out IT costs?
>>>> www.redhat.com/carveoutcosts/ <http://www.redhat.com/carveoutcosts/>
>>>>
>>>>
>>>> _______________________________________________
>>>> Freeipa-users mailing list
>>>> Freeipa-users at redhat.com <mailto:Freeipa-users at redhat.com>
>>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>>
>>> Starting clean after rebuilding ipa2 and desktop2 and a gdm login to
>>> ipa2 as dean, if I "ssh dean at desktop2 <mailto:dean at desktop2>" it
>>> will consistently fail as noted in my last note. However, if I:
>>>
>>> 1. su -
>>> 2. ssh dean at desktop2 <mailto:dean at desktop2>
>>> 3. logout of dean at desktop2 <mailto:dean at desktop2>
>>> 4. logout of root at ipa2 <mailto:root at ipa2>
>>>
>>> then "ssh dean at desktop2" <mailto:dean at desktop2> succeeds!
>>>
>>> Does that answer your question? So I do not think there is a race.
>>> It is more like the super user session leaves something behind that
>>> was missing?
>>
>> Does it succeed if after step 3 but before step 4 you do kdestoy?
>>
>>
>> --
>> Thank you,
>> Dmitri Pal
>>
>> Sr. Engineering Manager for IdM portfolio
>> Red Hat Inc.
>>
>>
>> -------------------------------
>> Looking to carve out IT costs?
>> www.redhat.com/carveoutcosts/ <http://www.redhat.com/carveoutcosts/>
>>
>
> Hah! Even better, it works the first time and every time, if I start
> with a kdestroy:
>
> 1. From Virtual Machine Manager open ipa2
> 2. Login as dean
> 3. Open a terminal
> 4. kdestroy
> 5. ssh dean at desktop2 <mailto:dean at desktop2>
> 6. logout
> 7. ssh dean at desktop2 <mailto:dean at desktop2>
> 8. logout
>
> Now, the fun starts. Why do it do that?
>
>
Now you need to see what you have before kdestroy.
Klist will help to see what cache is in play.
Then you need to see whether you as dean can access this cache (check
permissions and SELinux).
Based on the input you provided earlier the cache might be in
FILE:/tmp/krb5cc_1387400001
While after you login it is in
DIR::/run/user/1387400001/krb5cc/tktFDDxRR
The latter is the right one.
All applications in Fedora starting F18 should use DIR cache.
It seems that on this machine there is some other kerberized software
(NFS client?) that is not configured or updated to create DIR cache
style cache and continues to use FILE style cache. There have been a
slew of bugs around this. It seems you are hitting one of those.
Just FYI to avoid this confusion and to fight some race conditions
related to creation of the /run/user/uid directory the cache is now
moved to kernel and we are in process of updating different components
to use it.
--
Thank you,
Dmitri Pal
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20130911/419664ba/attachment.htm>
More information about the Freeipa-users
mailing list