Package: sudo Version: 1.8.19p1-2.1 Severity: normal X-Debbugs-CC: Luc Maisonobe <l...@spaceroots.org> X-Debbugs-CC: Jonas Meurer <jo...@freesources.org>
Dear Maintainer, sudo's pam config doesn't create a new keyring session for the processes it spawns. This leads to problems with programs that try to add things to the keyring, because they try to modify the user's keyring, which even root doesn't have permission to do. An example of this was mentioned in this previous bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758788#45 > On the first invocation (for cont1_crypt), I got this dialog: > > root@marislae:~# cryptdisks_start cont1_crypt > [[....] Starting crypto disk...[info] cont1_crypt (starting)... > Caching passphrase for /cont1: ****** > keyctl_set_timeout: Permission denied > Error setting timeout on key (2524288), removing > Caching passphrase for /cont1: ****** > keyctl_set_timeout: Permission denied > Error setting timeout on key (612589418), removing > > [Here I pressed <ctrl-C> to stop the attempts] > > Caching passphrase for /cont1: Erreur de lecture de la phrase secrète. > > > I was running the commands from root. I initially logged in to the > computer from SSH to a regular user, than did "sudo -i" to get root > access if this matters. As I suspected this may be a problem, I allowed > root direct SSH access and tried again, login directly to root account, > this time it worked: > > root@marislae:~# cryptdisks_start cont1_crypt > [....] Starting crypto disk...[info] cont1_crypt (starting)... > Caching passphrase for /cont1: ****** > [ ok _crypt (started)...done. > root@marislae:~# cryptdisks_start cont2_crypt > [....] Starting crypto disk...[info] cont2_crypt (starting)... > Using cached passphrase for /cont2. > [ ok _crypt (started)...done. It turns out that this works when logged in as root via SSH because this line in `/etc/pam.d/sshd` sets up a new session keyring for the root user: > # Create a new session keyring. > session optional pam_keyinit.so force revoke The same line is also present in `/etc/pam.d/runuser-l`, so I've been working around this problem by running cryptdisks_start via `sudo runuser -l`, as in: > sudo runuser -l root -c 'cryptdisks_start c1 && cryptdisks_start c2 && # so on' Given that it's not useful for a process running on the root user to try to manipulate the user's session keyring, I think it would make sense for /etc/pam.d/sudo to force the creation of a new one, or at least for `sudo -i` to force the creation of a new one via a `/etc/pam.d/sudo-i` config file, similar to `runuser -l`. Thanks, Simon -- System Information: Debian Release: 9.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (102, 'testing'), (101, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-7-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages sudo depends on: ii libaudit1 1:2.6.7-2 ii libc6 2.27-5 ii libpam-modules 1.1.8-3.6 ii libpam0g 1.1.8-3.6 ii libselinux1 2.6-3+b3 ii lsb-base 9.20161125 sudo recommends no packages. sudo suggests no packages. -- Configuration Files: /etc/sudoers [Errno 13] Permission denied: '/etc/sudoers' /etc/sudoers.d/README [Errno 13] Permission denied: '/etc/sudoers.d/README' -- no debconf information
