Crouton: Cannot create files in `~/Downloads`

[kapilhp]

name: test
encrypted: no
Entering /mnt/stateful_partition/crouton/chroots/test...
crouton: version 1-20180718130616~master:5d4c3014
release: buster
architecture: amd64
targets: core
host: version 10575.58.0 (Official Build) stable-channel cyan 
kernel: Linux localhost 3.18.0-17554-g9194949d4df2 #1 SMP PREEMPT Fri Jun 22 17:35:45 PDT 2018 x86_64 GNU/Linux
freon: yes
Unmounting /mnt/stateful_partition/crouton/chroots/test...

Please describe your issue:

Inside the chroot cannot create files in ~/Downloads.

1. If you copy a file with cp ~/.profile ~/Downloads/test you get an error message as below:

   cp: cannot create regular file '/home/kapil/Downloads/test': Required key not available`

   This also leaves behind a 0 byte file /home/kapil/Downloads/test.

2. If you try to edit a file with vi ~/Downloads/test then you get the "swap file already exists" message and there are files .test.swo and .test.swp in ~/Downloads. You can also no save a file to ~/Downloads.

If known, describe the steps to reproduce the issue:

1. Create a minimal chroot with sudo crouton -t core -r buster -n test

2. Enter the chroot with sudo enter-chroot -n test.

3. Try the copy command cp ~/.profile ~/Downloads/test.

[kapilhp]

The problem arose some time after 2018-07-29 14:39:15 (+5:30) which is the last time when I updated the chroot!
The problem could not be with crouton since croutonversion gives 1-20180718130616.
So there is some change in buster packages since that date which is causing a problem. Since this is a "key error", perhaps one needs to check on ecryptfs?

[kapilhp]

This seems to be a recurrence of #3261.

Edit: Also see "Link user keychain to session keychain" #3246.

[kapilhp]

TL;DR Looks like su - in buster is the culprit.

It looks like the loss of permission comes with the last su - "$USERNAME" command in enter-chroot. If this is replaced with the (apparently) functionally equivalent sudo -i -u "$USERNAME" command, then the error disappears!

Further investigation is required as I have only checked this in a separate test chroot which has minimal packages installed.

[kapilhp]

Looking into /etc/pam.d/su-l we find:

#%PAM-1.0
auth        include     su
account     include     su
password    include     su
session     optional    pam_keyinit.so force revoke
session     include     su

The line revoking the keys is what causes the difficulties. This file was dropped there by util-linux which has now taken over su from coreutils in buster. Moreover, the ReleaseNotes (v2.22) for util-linux explains that /etc/pam.d/su-l is used when su - or su -l or su --login is used.

Edit: Added a bug report to util-linux so that this change is highlighted to avoid such problems.

[sunaku]

Thanks @kapilhp, your suggestion in https://github.com/dnschneid/crouton/issues/3860#issuecomment-411264757 for changing su - into sudo -i -u fixed the problem for me, which affects Debian buster under the latest crouton release (at the time of this writing).

[Asternitix]

I've got the same problem, what's the fix?

[Asternitix]

thanks for the link, yup it works.

[ihexon]

but the ssh deamon still have the key error ,how should i fix it ?

[brizzbane]

Is there a fix for this? @Asternitix you mention a link, but don't see one. Was it via PM? Can you share?

Not following the comment for using the command 'sudo -i -u' ...once in the chroot, instead of just sudo su? ....Tried that, and still have error.

(Also on buster)

[Asternitix]

it was a link to a comment on this thread. sunaku posted it

[kapilhp]

For the time being a solution is to edit /etc/pam.d/su-l and /etc/pam.d/runuser-l (within the chroot) and comment out the line:
session optional pam_keyinit.so force revoke
Note that this has some security implications, but they may not (or may!) be serious. Basically this allows the user access to all the keys that root has access to when the user does an su.

[JL2210]

This is honestly not surprising coming from Ubuntu..

[Project-Fi]

For the time being _a_ solution is to edit /etc/pam.d/su-l and /etc/pam.d/runuser-l (within the chroot) and comment out the line:
session optional pam_keyinit.so force revoke
Note that this has some security implications, but they may not (or may!) be serious. Basically this allows the user access to all the keys that root has access to _when_ the user does an su.

Thanks!

[Asternitix]

2020 calling, @sunaku the fix you linked to still works