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.

Sign up for GitHub

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

Jump to bottom

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
Labels
stale upstreambug

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 •
edited
Loading

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 •
edited
Loading

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.

@kapilhp kapilhp mentioned this issue Aug 9, 2018
Closed
0xMF added a commit to 0xMF/dotfiles that referenced this issue Aug 25, 2018
@0xMF
reduces errors when crouton starts up
96a021b 
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 •
edited
Loading

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 •
edited
Loading

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.

dnschneid added a commit that referenced this issue Dec 7, 2018
@dnschneid
Use sudo instead of su.
fb40bff 
Fixes #3860
@dnschneid dnschneid mentioned this issue Dec 7, 2018
Open
@DennisLfromGA DennisLfromGA mentioned this issue Dec 28, 2018
Closed
@Asternitix Asternitix mentioned this issue Dec 31, 2018
Closed
dnschneid added a commit that referenced this issue Jan 17, 2019
@dnschneid
Use sudo instead of su.
d1b6f54 
Fixes #3860
dnschneid added a commit that referenced this issue Jan 18, 2019
@dnschneid
Use sudo instead of su.
acb2207 
Fixes #3860
@JL2210
Copy link

JL2210 commented Jan 30, 2019

This is honestly not surprising coming from Ubuntu..

@Hagb Hagb mentioned this issue Jul 28, 2019
Open
@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!

@DennisLfromGA DennisLfromGA mentioned this issue May 18, 2020
Closed
@Asternitix
Copy link

Asternitix commented May 27, 2020 •
edited
Loading

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
Assignees
No one assigned
Labels
stale upstreambug
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Use sudo instead of su. dnschneid/crouton
9 participants
@sunaku @dnschneid @DennisLfromGA @brizzbane @kapilhp @Asternitix @ihexon @dodfsk @JL2210