[Freeipa-devel] [PATCH] 439 Allow kernel keyring CCACHE when supported

[Alexander Bokovoy]

On Mon, 02 Dec 2013, Martin Kosek wrote:
>On 12/02/2013 04:05 PM, Petr Viktorin wrote:
>> On 12/02/2013 03:42 PM, Simo Sorce wrote:
>>> On Mon, 2013-12-02 at 14:51 +0100, Petr Viktorin wrote:
>>>> On 12/02/2013 02:01 PM, Martin Kosek wrote:
>>>>> On 12/02/2013 01:58 PM, Petr Viktorin wrote:
>>>>>> On 11/29/2013 01:48 PM, Martin Kosek wrote:
>>>>>>> On 11/19/2013 12:35 PM, Petr Viktorin wrote:
>>>>>>>> On 11/05/2013 07:22 PM, Martin Kosek wrote:
>>>>>>>>> Server and client installer should allow kernel keyring ccache when
>>>>>>>>> supported.
>>>>>>
>>>>>>>>
>>>>>>>> How do I enable the kernel keyring? On f20 I get this:
>>>>>>>>
>>>>>>>> 2013-11-19T11:28:07Z DEBUG Starting external process
>>>>>>>> 2013-11-19T11:28:07Z DEBUG args=keyctl get_persistent @s 0
>>>>>>>> 2013-11-19T11:28:07Z DEBUG Process finished, return code=1
>>>>>>>> 2013-11-19T11:28:07Z DEBUG stdout=
>>>>>>>> 2013-11-19T11:28:07Z DEBUG stderr=keyctl_get_persistent: Key has been
>>>>>>>> revoked
>>>>>>>
>>>>>>> It should be enabled out of the box. But there were some initial issues with
>>>>>>> persistent keyring in the first versions of kernel with a support, hopefully
>>>>>>> this was just a fluke which disappeared.
>>>>>>>
>>>>>>> This is what I see on my F20 with kernel-3.11.9-300.fc20.x86_64:
>>>>>>>
>>>>>>> # keyctl get_persistent @s 0
>>>>>>> 637466038
>>>>>>
>>>>>> With kernel-3.11.10-300.fc20.x86_64, I get an error again:
>>>>>> $ keyctl get_persistent @s 0
>>>>>> keyctl_get_persistent: Key has been revoked
>>>>>
>>>>> Not sure if it is a typo, but you won't surely get a root's keyring as a
>>>>> non-root user...
>>>>
>>>> It is just a typo, but it looks like you got me on the right track.
>>>> keyctl apparently needs a real root login:
>>>>
>>>> $ sudo keyctl get_persistent @s 0
>>>> keyctl_get_persistent: Key has been revoked
>>>>
>>>> $ sudo su
>>>> # keyctl get_persistent @s 0
>>>> keyctl_get_persistent: Key has been revoked
>>>> # exit
>>>>
>>>> $ sudo su -
>>>> Last login: Mon Dec  2 14:09:36 CET 2013 on pts/1
>>>> # keyctl get_persistent @s 0
>>>> 968622527
>>>> # logout
>>>>
>>>
>>> Please use "sudo -i" to get an interactive 'login' shell.
>>>
>>>> Unsurprisingly, when ipa-server-install is run from sudo, it complains
>>>> that the key is unsupported. From a root login all is OK.
>>>>
>>>> Is that expected?
>>>
>>> You should run ipa-server-install using a login shell I think.
>>> Should we open a bug to detect this and fail ?
>>
>> It's always worked with just sudo for me. So yes, if it's required I think we
>> should enforce it.
>>
>
>Simo or Alexander, is there some way to find that out in a clean way? I mean if
>we are in an interactive login shell. Ideally, please also file a bug with this
>information :)
Interactive or login? These two are different a bit.

There is no general way because not all shells implement common approach
to detect this. For example, 

     echo $- | grep -q i

would work in a Bourne-style shell for interactive shell

     shopt -q login_shell

would give you a login shell detector in bash but

     test $options[LOGIN] = on

would work for login shell in zsh, similarly INTERACTIVE index would
give you state of interactive shell.


-- 
/ Alexander Bokovoy