Thread (18 messages) 18 messages, 3 authors, 2019-04-25

Re: [PATCH 07/11] keys: Move the user and user-session keyrings to the user_namespace

From: David Howells <dhowells@redhat.com>
Date: 2019-04-25 11:38:32
Also in: keyrings, linux-fsdevel, lkml

Jann Horn [off-list ref] wrote:
quoted
+       struct key              *user_keyring_register;
Maybe a comment about locking semantics above user_keyring_register?
"Only written once, may be read locklessly with READ_ONCE()", or
something like that?
Ok.
quoted
-
+#define __KDEBUG
Was that supposed to be in here, or did you commit that accidentally?
Accidental.
quoted
-       struct key *uid_keyring, *session_keyring;
+       struct key *reg_keyring = user_ns->user_keyring_register;
This is a lockless read of a field that may be written concurrently;
this should be READ_ONCE(). (Especially on alpha, I think the memory
ordering will actually be incorrect without READ_ONCE().)
Yeah, you're right about both of these that you pointed out.  It's not needed
when the user_ns->keyring_sem is taken for writing, however.
quoted
+               if (!IS_ERR(reg_keyring))
+                       user_ns->user_keyring_register = reg_keyring;
This is a write of a pointer that may be read concurrently; this
should be smp_store_release().
Yep.
quoted
+       else if ((user_session = get_user_session_keyring())) {
+               key_ref = keyring_search_aux(make_key_ref(user_session, 1),
+                                            ctx);
                if (!IS_ERR(key_ref))
                        goto found;
I'm not sure I understand this code. In the "goto found" case, the
key_put() below is skipped, right? Is that intentional?
Actually, the key_put() should be directly after the keyring_search_aux()
call, before the error check.
quoted
 error_alloc:
        complete_request_key(authkey, ret);
+error_us:
+       key_put(user_session);
        kleave(" = %d", ret);
        return ret;
 }
This looks weird. If the look_up_user_keyrings() fails, user_session
might still be an uninitialized pointer, right? And then the "goto
error_us" jumps down here and calls key_put() on that?
The call to complete_request_key() should be after error_us and the key_put()
should be before it.
quoted
@@ -289,16 +291,19 @@ static int construct_get_dest_keyring(struct key **_dest_keyring)

                        if (dest_keyring)
                                break;
+                       /* Fall through */

                        /* fall through */
                case KEY_REQKEY_DEFL_USER_SESSION_KEYRING:
Why two "fall through" comments?
Someone else added one and when I rebased, I don't think I got a conflict.

David
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help