Le samedi 24 janvier 2015 à 20:40 -0500, Benjamin Kaduk a écrit : > On Fri, 23 Jan 2015, Yvan Masson wrote: > > > Le jeudi 22 janvier 2015 à 19:34 -0500, Jason Edgecombe a écrit : > > > On 01/22/2015 12:53 PM, Yvan Masson wrote: > > > > Thanks for your fast answers. > > > > > > > > Le mardi 20 janvier 2015 à 20:37 -0500, Jason Edgecombe a écrit : > > > >> On 01/20/2015 03:46 PM, Benjamin Kaduk wrote: > > > >>> Hi, > > > >>> > > > >>> On Tue, 20 Jan 2015, Yvan Masson wrote: > > > >>> > > > > The most important for me would just one command (for example "sudo > > > > ls"). > > Hmm, 'sudo ls' should not be invoking a new copy of the shell, IIRC, so I > do not think that ~/.bash_logout or similar would be at fault. > > > > >> Is only the > > > >>> terminal where sudo was run affected, or are other terminal windows > > > >>> affected as well? > > > > If I use sudo in gnome-terminal for example, the token is lost for this > > > > terminal and for all my X session: this is my biggest problem. But if I > > > > have also a running TTY, the token in my TTY is not destroyed. > > > >>>> I suppose that I should do someting with PAM, probably > > > >>>> in /etc/pam.d/sudo, but I don't know exactly what. > > > >>> Well, it probably depends on whether the default (uid-based) pag is in > > > >>> use, or a session-specific pag. > > > >>> > > > >>> I think that with jessie's kernel the pag information is stored in the > > > >>> keyring, so 'keyctl show' before and after sudo is run may be helpful. > > > > Pardon, but I don't know how to use this tool: can I run it from a > > > > terminal ? > > I finally understood that I needed the keyutils package... So if run > > "keyctl show" before and after a sudo command, the results are exactly > > identical : > > $ keyctl show > > Session Keyring > > 901610366 ---lswrv 0 1000 keyring: _ses.2400 > > 130758458 ----s--v 0 0 \_ afs_pag: _pag > > Hmm, this leaves me somewhat confused. > > Is pam_afs_session present in any pam configuration files? > (grep -r pam_afs_session /etc/pam.d) Yes, pam_afs_session is in some pam files : common-auth, common-session and common-session-noninteractive. These files are attached. Indeed, I suppose something is wrong here. > > -Ben
# # /etc/pam.d/common-auth - authentication settings common to all services # # This file is included from other service-specific PAM config files, # and should contain a list of the authentication modules that define # the central authentication scheme for use on the system # (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the # traditional Unix authentication mechanisms. # # As of pam 1.0.1-6, this file is managed by pam-auth-update by default. # To take advantage of this, it is recommended that you configure any # local modules either before or after the default block, and use # pam-auth-update to manage selection of other modules. See # pam-auth-update(8) for details. # here are the per-package modules (the "Primary" block) auth [success=2 default=ignore] pam_unix.so nullok_secure auth [success=1 default=ignore] pam_krb5.so minimum_uid=1000 try_first_pass # here's the fallback if no module succeeds auth requisite pam_deny.so # prime the stack with a positive return value if there isn't one already; # this avoids us returning an error just because nothing sets a success code # since the modules above will each just jump around auth required pam_permit.so # and here are more per-package modules (the "Additional" block) auth optional pam_afs_session.so auth optional pam_cap.so # end of pam-auth-update config
# # /etc/pam.d/common-session - session-related modules common to all services # # This file is included from other service-specific PAM config files, # and should contain a list of modules that define tasks to be performed # at the start and end of sessions of *any* kind (both interactive and # non-interactive). # # As of pam 1.0.1-6, this file is managed by pam-auth-update by default. # To take advantage of this, it is recommended that you configure any # local modules either before or after the default block, and use # pam-auth-update to manage selection of other modules. See # pam-auth-update(8) for details. # here are the per-package modules (the "Primary" block) session [default=1] pam_permit.so # here's the fallback if no module succeeds session requisite pam_deny.so # prime the stack with a positive return value if there isn't one already; # this avoids us returning an error just because nothing sets a success code # since the modules above will each just jump around session required pam_permit.so # and here are more per-package modules (the "Additional" block) session optional pam_krb5.so minimum_uid=1000 session required pam_unix.so session optional pam_afs_session.so session optional pam_ck_connector.so nox11 session optional pam_systemd.so # end of pam-auth-update config
# # /etc/pam.d/common-session-noninteractive - session-related modules # common to all non-interactive services # # This file is included from other service-specific PAM config files, # and should contain a list of modules that define tasks to be performed # at the start and end of all non-interactive sessions. # # As of pam 1.0.1-6, this file is managed by pam-auth-update by default. # To take advantage of this, it is recommended that you configure any # local modules either before or after the default block, and use # pam-auth-update to manage selection of other modules. See # pam-auth-update(8) for details. # here are the per-package modules (the "Primary" block) session [default=1] pam_permit.so # here's the fallback if no module succeeds session requisite pam_deny.so # prime the stack with a positive return value if there isn't one already; # this avoids us returning an error just because nothing sets a success code # since the modules above will each just jump around session required pam_permit.so # and here are more per-package modules (the "Additional" block) session optional pam_krb5.so minimum_uid=1000 session required pam_unix.so session optional pam_afs_session.so # end of pam-auth-update config
