On Wed, 23 Jun 2010 at 16:10:47 -0700, Steve Langasek wrote: > On Mon, Jun 21, 2010 at 11:18:38PM +1000, Russell Coker wrote: > > reassign 560281 libpam0g > > thanks > > > The auid is not set by auditd, it is set by the login program. > > > session required pam_loginuid.so > > This PAM module should only be used for entry point applications like: > login, sshd, gdm, vsftpd, crond and atd.
[...] > My understanding is > that pam_loginuid is only useful when operating in conjunction with auditd It seems it has other uses: it writes to /proc/$pid/loginuid, which sets the loginuid (auditd's "auid"), but as a side-effect this also allocates a session ID in /proc/$pid/sessionid which can be used as a general way to identify a login session (ConsoleKit and systemd use it when available, for instance). <http://0pointer.de/blog/projects/ids.html> notes that sessionid is always (uint32_t)(-1) ("not in a session") in current Ubuntu and Debian. I suspect that technologies originating from Fedora/Red Hat are more likely to rely on sessionid, since they have SELinux by default anyway. Looking at kernel source, it seems new sessions can be started whenever, but only with the CAP_AUDIT_CONTROL capability. Perhaps the solution for this is to add pam_loginuid to the pam.d files for all the common entry points; or to have a common-session-login alongside common-session and common-session-noninteractive, and use that in the entry-point apps, but not in privilege-escalation tools like su and sudo? S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
