[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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³


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]