New issue
Advanced search Search tips

Issue 593893 link

Starred by 3 users

Issue metadata

Status: Archived
Owner:
Closed: Mar 2017
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug

Blocking:
issue 347322



Sign in to add a comment

ecryptfs broken when creating a session keyring

Project Member Reported by gwendal@chromium.org, Mar 10 2016

Issue description

I am making a change to upstart to create a session keyring (called e4crypt). (https://chromium-review.googlesource.com/#/c/331340/)

keyctl show
Session Keyring
 771055865 --alswrv      0     0  keyring: _ses
  63587131 --alswrv      0     0   \_ keyring: e4crypt

However, when that keyring is created, we can not mount ecryptfs partition:
2016-03-10T13:04:36.181378-08:00 ERR cryptohomed[1150]: Cryptohome mount failed for vault /home/.shadow/4ef6c64312576e739bc0bea986aa439db8fdf7e9/vault: No such file or directory
2016-03-10T13:04:36.181663-08:00 ERR kernel: [ 2686.047522] Could not find key with description: [dd6f92bd8660b36c]
2016-03-10T13:04:36.181672-08:00 WARNING kernel: [ 2686.047540] process_request_key_err: No key
2016-03-10T13:04:36.181677-08:00 ERR kernel: [ 2686.047548] Could not find valid key in user session keyring for sig specified in mount option: [dd6f92bd8660b36c]
2016-03-10T13:04:36.181681-08:00 WARNING kernel: [ 2686.047563] One or more global auth toks could not properly register; rc = [-2]
2016-03-10T13:04:36.181685-08:00 ERR kernel: [ 2686.047576] Error parsing options; rc = [-2]

However, the key is present in the user keyring:
keyctl show @us
Keyring
 549666721 --alswrv      0 65534  keyring: _uid_ses.0
 346719914 --alswrv      0 65534   \_ keyring: _uid.0
 235623693 --alswrv      0     0       \_ user: dd6f92bd8660b36c
 747773852 --alswrv      0     0       \_ user: 7025717e50fd74a2


When the e4 keyring is not created, ecryptfs partition are mounted as expected. The user session keyring shows as the default:
keyctl show
Session Keyring
 156475336 --alswrv      0 65534  keyring: _uid_ses.0
 344398901 --alswrv      0 65534   \_ keyring: _uid.0
 836501932 --alswrv      0     0       \_ user: a0cecf3a10c1a05a
 460403790 --alswrv      0     0       \_ user: 6e4f4e6114767a92

I need to understand why when ecryptfs call request key, the user keyring is not searched.


 
The problem is in search_my_process_keyrings()
We have
  /* search the process keyring second */
  if (ctx->cred->process_keyring) {
    ...
  }
  /* search the session keyring */
  if (ctx->cred->session_keyring) {
    ...
  }
  /* or search the user-session keyring */
  else if (ctx->cred->user->session_keyring) {
    ...
The else is killing me. Why if there is a session keyring, we can not search in the user session keyring.


Project Member

Comment 2 by bugdroid1@chromium.org, Mar 19 2016

Labels: merge-merged-chromeos-3.18
The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ca1673af67b0e40aeb368981c4326bba84822bb8

commit ca1673af67b0e40aeb368981c4326bba84822bb8
Author: Gwendal Grignou <gwendal@chromium.org>
Date: Thu Mar 10 22:04:31 2016

FROMLIST: keyrings: Allow searching the user session keyring

Currently, if a session keyring exists, we are not searching in the
user session or user keyrings.

This is a problem when a session keyring exists and we want to use
ecryptfs.

BUG= chromium:347322 , chromium:593893 
TEST=Without this change, mounting an ecryptfs "partition" fails when a
session keyring exists:
kernel: [ 2686.047522] Could not find key with description: [dd6f92bd8660b36c]
Although the key exits:
keyctl show @us
Keyring
 549666721 --alswrv      0 65534  keyring: _uid_ses.0
 346719914 --alswrv      0 65534   \_ keyring: _uid.0
 235623693 --alswrv      0     0       \_ user: dd6f92bd8660b36c
 747773852 --alswrv      0     0       \_ user: 7025717e50fd74a2
With this change, ecryptfs can see the keys it needs.

Note that 'keyctl show' still only shows the session keyring by default.
We need to specify 'keyctl show @us' to see the user session keyring
when the session keyring exits.

[http://www.spinics.net/lists/keyrings/msg00647.html]

Change-Id: I8c6a112a77b7ba40f07e6a579cc77d88af44146a
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/333383
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>

[modify] https://crrev.com/ca1673af67b0e40aeb368981c4326bba84822bb8/security/keys/process_keys.c

Project Member

Comment 3 by bugdroid1@chromium.org, Mar 21 2016

Labels: merge-merged-stabilize-smaug-7897.B-chromeos-3.18
The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/9fe6e50141cea3d9e333d3562fd8d2ef64d200b0

commit 9fe6e50141cea3d9e333d3562fd8d2ef64d200b0
Author: Gwendal Grignou <gwendal@chromium.org>
Date: Thu Mar 10 22:04:31 2016

FROMLIST: keyrings: Allow searching the user session keyring

Currently, if a session keyring exists, we are not searching in the
user session or user keyrings.

This is a problem when a session keyring exists and we want to use
ecryptfs.

BUG= chromium:347322 , chromium:593893 
TEST=Without this change, mounting an ecryptfs "partition" fails when a
session keyring exists:
kernel: [ 2686.047522] Could not find key with description: [dd6f92bd8660b36c]
Although the key exits:
keyctl show @us
Keyring
 549666721 --alswrv      0 65534  keyring: _uid_ses.0
 346719914 --alswrv      0 65534   \_ keyring: _uid.0
 235623693 --alswrv      0     0       \_ user: dd6f92bd8660b36c
 747773852 --alswrv      0     0       \_ user: 7025717e50fd74a2
With this change, ecryptfs can see the keys it needs.

Note that 'keyctl show' still only shows the session keyring by default.
We need to specify 'keyctl show @us' to see the user session keyring
when the session keyring exits.

[http://www.spinics.net/lists/keyrings/msg00647.html]

Change-Id: I8c6a112a77b7ba40f07e6a579cc77d88af44146a
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Previous-Reviewed-on: https://chromium-review.googlesource.com/333383
(cherry picked from commit fa5e917c550817789c6bd8df3d0a987232fe085d)
Reviewed-on: https://chromium-review.googlesource.com/334272

[modify] https://crrev.com/9fe6e50141cea3d9e333d3562fd8d2ef64d200b0/security/keys/process_keys.c

Project Member

Comment 4 by bugdroid1@chromium.org, May 4 2016

Labels: merge-merged-chromeos-4.4
The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/287f0106377b9256191ae8df3b879b56091412df

commit 287f0106377b9256191ae8df3b879b56091412df
Author: Gwendal Grignou <gwendal@chromium.org>
Date: Thu Mar 10 22:04:31 2016

FROMLIST: keyrings: Allow searching the user session keyring

Currently, if a session keyring exists, we are not searching in the
user session or user keyrings.

This is a problem when a session keyring exists and we want to use
ecryptfs.

BUG= chromium:347322 , chromium:593893 
TEST=Without this change, mounting an ecryptfs "partition" fails when a
session keyring exists:
kernel: [ 2686.047522] Could not find key with description: [dd6f92bd8660b36c]
Although the key exits:
keyctl show @us
Keyring
 549666721 --alswrv      0 65534  keyring: _uid_ses.0
 346719914 --alswrv      0 65534   \_ keyring: _uid.0
 235623693 --alswrv      0     0       \_ user: dd6f92bd8660b36c
 747773852 --alswrv      0     0       \_ user: 7025717e50fd74a2
With this change, ecryptfs can see the keys it needs.

Note that 'keyctl show' still only shows the session keyring by default.
We need to specify 'keyctl show @us' to see the user session keyring
when the session keyring exits.

[http://www.spinics.net/lists/keyrings/msg00647.html]

Change-Id: I8c6a112a77b7ba40f07e6a579cc77d88af44146a
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/333383
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
(cherry picked from commit ca1673af67b0e40aeb368981c4326bba84822bb8)
Reviewed-on: https://chromium-review.googlesource.com/341972
Reviewed-by: Guenter Roeck <groeck@google.com>

[modify] https://crrev.com/287f0106377b9256191ae8df3b879b56091412df/security/keys/process_keys.c

Owner: gwendal@chromium.org
Status: Started (was: Untriaged)
Project Member

Comment 6 by bugdroid1@chromium.org, Jul 2 2016

Labels: merge-merged-chromeos-3.14
The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/3e45a01bf88fcc1b1042f1993229fd6d1e7b25c1

commit 3e45a01bf88fcc1b1042f1993229fd6d1e7b25c1
Author: Gwendal Grignou <gwendal@chromium.org>
Date: Thu Mar 10 22:04:31 2016

FROMLIST: keyrings: Allow searching the user session keyring

Currently, if a session keyring exists, we are not searching in the
user session or user keyrings.

This is a problem when a session keyring exists and we want to use
ecryptfs.

BUG= chromium:347322 , chromium:593893 
TEST=Without this change, mounting an ecryptfs "partition" fails when a
session keyring exists:
kernel: [ 2686.047522] Could not find key with description: [dd6f92bd8660b36c]
Although the key exits:
keyctl show @us
Keyring
 549666721 --alswrv      0 65534  keyring: _uid_ses.0
 346719914 --alswrv      0 65534   \_ keyring: _uid.0
 235623693 --alswrv      0     0       \_ user: dd6f92bd8660b36c
 747773852 --alswrv      0     0       \_ user: 7025717e50fd74a2
With this change, ecryptfs can see the keys it needs.

Note that 'keyctl show' still only shows the session keyring by default.
We need to specify 'keyctl show @us' to see the user session keyring
when the session keyring exits.

[http://www.spinics.net/lists/keyrings/msg00647.html]

Reviewed-on: https://chromium-review.googlesource.com/333383
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
(cherry picked from commit ca1673af67b0e40aeb368981c4326bba84822bb8)
Change-Id: I8c6a112a77b7ba40f07e6a579cc77d88af44146a
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/347691
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>

[modify] https://crrev.com/3e45a01bf88fcc1b1042f1993229fd6d1e7b25c1/security/keys/process_keys.c

Comment 7 by uekawa@chromium.org, Nov 29 2016

Can this be marked fixed?
Status: Fixed (was: Started)
Project Member

Comment 9 by bugdroid1@chromium.org, Mar 30 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/f13cb7f69fba9ae244d2d38651902babaeb45c80

commit f13cb7f69fba9ae244d2d38651902babaeb45c80
Author: Gwendal Grignou <gwendal@chromium.org>
Date: Thu Mar 30 19:18:14 2017

Revert "FROMLIST: keyrings: Allow searching the user session keyring"

This reverts commit 3e45a01bf88f ("FROMLIST: keyrings: Allow searching
the user session keyring")
It is not needed anymore: It was used for access the user session
keyring by cryptohomed in ecryptfs mode.

But since we only access these keys when we mount the user directories,
and we don't need them after that, we can link the user session through
the process keyring, as cryptohome now does in CL:440049

BUG= chromium:593893 
CQ-DEPEND=CL:440049
TEST=Check on Veyron that cryptohomed can mount previously created
ecryptfs mounts, even with option --direncryption

Change-Id: Idbd2f7314d40674ac4ad97d39d82111b2e14deff
Reviewed-on: https://chromium-review.googlesource.com/462363
Commit-Ready: Gwendal Grignou <gwendal@chromium.org>
Tested-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Ryo Hashimoto <hashimoto@chromium.org>

[modify] https://crrev.com/f13cb7f69fba9ae244d2d38651902babaeb45c80/security/keys/process_keys.c

Project Member

Comment 10 by bugdroid1@chromium.org, Mar 31 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/0902ac5c0852faa8db760b385ffe4dd0fb33dfff

commit 0902ac5c0852faa8db760b385ffe4dd0fb33dfff
Author: Gwendal Grignou <gwendal@chromium.org>
Date: Fri Mar 31 19:59:17 2017

Revert"FROMLIST: keyrings: Allow searching the user session keyring"

This reverts commit 287f0106377b ("FROMLIST: keyrings: Allow searching
the user session keyring")
It is not needed anymore: It was used for access the user session
keyring by cryptohomed in ecryptfs mode.

But since we only access these keys when we mount the user directories,
and we don't need them after that, we can link the user session through
the process keyring, as cryptohome now does in CL:440049

BUG= chromium:593893 
CQ-DEPEND=CL:440049
TEST=Check on Veyron that cryptohomed can mount previously created
ecryptfs mounts, even with option --direncryption

Change-Id: I0a1b5f7a4c719d7c7067c34512ed0412a47a6856
Reviewed-on: https://chromium-review.googlesource.com/463966
Commit-Ready: Gwendal Grignou <gwendal@chromium.org>
Tested-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Ryo Hashimoto <hashimoto@chromium.org>

[modify] https://crrev.com/0902ac5c0852faa8db760b385ffe4dd0fb33dfff/security/keys/process_keys.c

Comment 11 by dchan@google.com, May 30 2017

Labels: VerifyIn-60
Labels: VerifyIn-61

Comment 13 by dchan@chromium.org, Jan 22 2018

Status: Archived (was: Fixed)

Sign in to add a comment