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

[Simo Sorce]

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.

-- 
Simo Sorce * Red Hat, Inc * New York