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

[Petr Viktorin]

On 12/06/2013 03:00 PM, Simo Sorce wrote:
> On Fri, 2013-12-06 at 13:42 +0100, Martin Kosek wrote:
>> On 12/02/2013 05:20 PM, Alexander Bokovoy wrote:
>>> 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.
>>>
>>>
>>
>> I meant login shell - so that we do not have problems with checking the
>> get_persistent keyctl command.
>>
>> I still do not fully understand the keyctl behavior, it is working on my
>> kernel-3.11.9-300.fc20.x86_64 even with plain "sudo":
>>
>> $ sudo keyctl get_persistent @s 0
>
> I think the previous behavior was cause by the improper selinux handling
> in the kernel, and is fixed in the latest kernel. There is indeed no
> reason why get_persistent shouldn't work for non-login shell unless
> selinux policy explicitly disallows it for sudo like programs.
>
>> Anyway, any opinions on this particular patch? I'd prefer to get it in soon and
>> file enhancement ticket for the login terminal detection, if needed.
>
> I do not have any objections.
>
> Simo.

ACK, pushed to
* master: 9677308caa78ed722570aea32f21334b8c27bad3
* ipa-3-3: 5b2ce3c5a57e8193ee1c6d23c4e79c3b2b62cb05


-- 
Petr³