Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot create files in ~/Downloads #3860

Closed
kapilhp opened this issue Aug 5, 2018 · 14 comments · May be fixed by #3956
Closed

Cannot create files in ~/Downloads #3860

kapilhp opened this issue Aug 5, 2018 · 14 comments · May be fixed by #3956

Comments

@kapilhp
Copy link

kapilhp commented Aug 5, 2018

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
Copy link
Author

kapilhp commented Aug 6, 2018

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
Copy link
Author

kapilhp commented Aug 7, 2018

This seems to be a recurrence of #3261.

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

@kapilhp
Copy link
Author

kapilhp commented Aug 8, 2018

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
Copy link
Author

kapilhp commented Aug 8, 2018

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.

0xMF added a commit to 0xMF/dotfiles that referenced this issue Aug 25, 2018
What change was done:

dpkg --get-selections > installed-packages.crouton

Why was this change made:

noticed a few errors in crouton shell when chroot sid started up, so
I added a bare minimum packages to remove those errors. I suggest
disabling audio in chroot via xfce4-settings rather than installing
a ton of audio-based libraries just to remove that startup error.

Also ensure /tmp/.ICE-unix and /tmp/.X11-unix are owned by root

Outstanding issues:

/etc/pam.d/su-l is broken, which I hacked by commenting out the
line mentioned in dnschneid/crouton#3860
to enable writing to ~/Downloads
@sunaku
Copy link

sunaku commented Sep 12, 2018

Thanks @kapilhp, your suggestion in #3860 (comment) 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
Copy link

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

@Asternitix
Copy link

thanks for the link, yup it works.

@ihexon
Copy link

ihexon commented Oct 18, 2018

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

@brizzbane
Copy link

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
Copy link

Asternitix commented Nov 29, 2018

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

@kapilhp
Copy link
Author

kapilhp commented Nov 30, 2018

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
Copy link

JL2210 commented Jan 30, 2019

This is honestly not surprising coming from Ubuntu..

@dodfsk
Copy link

dodfsk commented Nov 13, 2019

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
Copy link

Asternitix commented May 27, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants