+++ This bug was initially created as a clone of Bug #198623 +++ The "sudo" program can operate in "login" mode with the "-i" parameter. In this respect it is like "su - [user]" and should force a new keyring; in other situations it should not (as for "su [user]"). WHAT NEEDS TO BE DONE ===================== The PAM scripts for the login programs need to be altered to forcibly create a new session keyring when a login event occurs. These simply require the following line adding to their PAM scripts: session optional pam_keyinit.so force revoke This forces them to create a new session keyring during login, replacing the one inherited from their parent, and causes the session keyring so created to be revoked when the login process exits. Ideally, this should be "required" not "optional", but it still has to work if the pam_keyinit.so library is absent. The authlogin program needs modifying to add: session optional pam_keyinit.so revoke To the default session (system-auth). This just creates a new session keyring if one doesn't yet exist for this process. The "su" program needs to split its "su - [user]" mode PAM script from its "su [user]" PAM script, so that the former can forcibly create a keyring whilst the latter doesn't. -- Additional comment from dhowells on 2006-07-12 10:00 EST -- The keyring in question is the session keyring maintained by the kernel for each process and manageable through the keyutils package. -- Additional comment from harald on 2006-07-12 10:24 EST -- /usr/sbin/in.telnetd uses /bin/login $ rpm -qf /bin/login util-linux-2.13-0.20.3
Created attachment 132361 [details] Separate out PAM script for "sudo -i" and add keyinit instructions to samples Patch to make sudo use separate PAM scripts for "sudo" and "sudo -i". Also creates a new sample PAM script for "sudo -i" and adds appropriate keyinit instructions to both.
Created attachment 132362 [details] Modify SPEC file to add keyring initialisation to PAM scripts
David, I think your solution based on def_env_reset is not the best idea, because it could be enabled by the "Default env_reset" option in sudoers. I want to be sure, so I've rather used: +#ifdef HAVE_PAM_LOGIN + if (ISSET(sudo_mode, MODE_LOGIN_SHELL)) + pam_status = pam_start("sudo-i", pw->pw_name, &pam_conv, &pamh); + else +#endif + pam_status = pam_start("sudo", pw->pw_name, &pam_conv, &pamh); and added HAVE_PAM_LOGIN to configure.in. I think it's a way which could be accepted by upstream (I hope:-). Thanks for your work.
Karel - are your concerns regarding David's proposed approach, and subsequent alternative implementation, applicable to the numerous other login type utilities? I ask this question because there are about 10 packages with the same fix suggested. So I'm not sure if the other packages are ok as-is or whether they should consider your alternative approach.
Tim, this thing (in comment #4) is sudo specific and doesn't have impact to the others packages. For login processes (= create new session) we need "force revoke" and for the rest we need "revoke" in PAM setting. The sudo command is specific, because it supports both modes. So, we need a way how do distinction between this modes in sudo code. My concern was about the way how David has done this distinction.