fscrypt: required key not available in docker container

If I mount an encrypted folder into a docker container, it seems I can’t write to that folder from within the container per the following:

$ fscrypt status /home/kzidane/
"/home/kzidane/" is encrypted with fscrypt.

Policy:   37064e515e94c9a0
Unlocked: Yes

Protected with 1 protector:
PROTECTOR         LINKED   DESCRIPTION
2fe3444e16452da0  Yes (/)  login protector for kzidane
$ docker run -it --rm -v/home/kzidane:/root/tmp ubuntu bash -c 'echo foo > /root/tmp/foo'
bash: /root/tmp/foo: Required key not available

Any way to fix this by chance?

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.10
Release:        18.10
Codename:       cosmic

$ fscrypt --version
fscrypt - A tool for managing Linux filesystem encryption

Version:
  v0.2.4-24-g8956903

Compiled:
  2019-03-05 11:13:16 -0500 EST

Author:
  Joe Richey <joerichey@google.com>

Copyright:
  Copyright 2017 Google, Inc.

  Licensed under the Apache License, Version 2.0 (the "License");
  you may not use this file except in compliance with the License.
  You may obtain a copy of the License at

      http://www.apache.org/licenses/LICENSE-2.0

  Unless required by applicable law or agreed to in writing, software
  distributed under the License is distributed on an "AS IS" BASIS,
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  See the License for the specific language governing permissions and
  limitations under the License.


$ docker --version
Docker version 18.09.3, build 774a1f4

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 24 (4 by maintainers)

Commits related to this issue

Most upvoted comments

The solution to this problem was merged in #148, so I’m closing this.

However, due to the prerequisite of kernel v5.4 or later, the fix is currently “opt-in” via a setting in /etc/fscrypt.conf. See the new Troubleshooting section for how to enable it.

https://github.com/google/fscrypt/issues/182 tracks making new installations of fscrypt use v2 encryption policies by default when kernel support is detected.

+3
ebiggers on Jun 14, 2021

Why is this problem exclusive to fscrypt, in contrast to other encryption methods?

It’s because fscrypt (the kernel portion) looks up the key in the accessing process’ session keyring each time an encrypted file is opened, whereas the other solutions look up the encryption key one time when the filesystem is mounted. This is indeed inconsistent with the other FS caches being systemwide.

I’m planning to send a pull request for the new fscrypt API for Linux v5.4. The new API allows adding/removing keys directly from the filesystem. So after that is merged, we’ll be able to fix this.

+2
ebiggers on Aug 21, 2019

Sorry for the delay in replying, I just got back from leave.

@kzidane @nawarnoori so the main issue here is that kernel namespaces (which containers use) do not play nicely with the kernel keyrings (which the fscrypt kernel component uses for key management). I’ve been looking into this problem for awhile, mainly on how to fix this without modifying the kernel.

I can start experimenting with docker configs and kernel configs to make this work. But actually fixing this problem will require more extensive changes to the kernel.

There are a bunch of relevant kernel patchsets in progress to actually fix this, but they will take awhile to be merged and filter down to most users of Linux.

+2
josephlr on Apr 8, 2019

Yes, you need to wait for https://github.com/google/fscrypt/pull/148 to be merged (or try it out early if you’re adventurous) in order to take advantage of the new features in kernel v5.4.

+1
ebiggers on Dec 4, 2019

Yes, the kernel patches will be in 5.4. The userspace patches are still under review at https://github.com/google/fscrypt/pull/148.

+1
ebiggers on Nov 12, 2019

I’ve installed fscrypt version 0.2.0, how can I apply this patch: https://patchwork.kernel.org/cover/10881911/ Do I need to modify the source code and build it myself?

Yes, and in addition to building a custom kernel you’d also need to build your own version of the fscrypt tool from my experimental branch, which is linked to from the kernel patchset’s cover letter. Then you’d need to delete your encrypted directories and re-create them using the new encryption policy version. (The new kernel API works with existing encrypted directories too, but my changes to the fscrypt tool don’t take advantage of that yet.) And my changes to the fscrypt tool are still experimental and might contain bugs. But if you understand all this and would like to help test it, please go ahead; it would be appreciated.

I’ve still been pushing to get the kernel patches merged, but they still need review and sign off from the other fscrypt (kernel-side) maintainers, and we all tend to be very busy on other projects. It would also be helpful if more people would participate in the discussion on the linux-fscrypt mailing list.

+1
ebiggers on Jun 17, 2019

I’ve installed fscrypt version 0.2.0, how can I apply this patch: https://patchwork.kernel.org/cover/10881911/ Do I need to modify the source code and build it myself?

Yes, you would have to rebuild the kernel. I would use the v6 patchset. @ebiggers has a patchset for this tool that will support these new policies. I need a good way to test this with the CI before merging it, but hopefully the patches will get merged upstream soon.

+1
josephlr on Jun 17, 2019
Read more comments on GitHub
← fscrypt: PAM login failure after update to bd2ca31
fuzzbench: ankou fuzzer is disabled due to OOMs, need higher configuration vms →