On Wed, Aug 12, 2009 at 05:01:16PM -0500, Brian Cameron wrote: > >I don't understand why you think this isn't appropriate use of PAM. > > I discussed this with Gary Winiger several months ago and he seemed > insistent that this was an inappropriate use of PAM. He said that if > we wanted programs to integrate with ConsoleKit, they should integrate > directly (as GDM does), and not use a PAM module for this purpose. If > my understanding of Gary's concerns are correct, he seemed to feel that > PAM was to be used for authorization purposes, and not to keep random > databases up to date. > > I've cc:ed Gary. Hopefully he can elaborate his views on this. Unless > I am confused it seems that you and he have different perspectives on > this.
PAM includes "session management". Just what that means is a bit nebulous, but a) the "hook" is there, b) the login apps that deal in "sessions" do call PAM session management functions, therefore I don't see why modules that make use of it would be inappropriate. But that's not the question here (see below). Login apps should update the system's login accounting databases, but as we're seeing here, there's a desire to replace those. PAM makes it possible to replace those dynamically. But there are some good [and/or some lame] reasons for not wanting to rely on PAM for this: - There aren't sufficient PAM items by which to convey to modules all the possibly relevant information (e.g., client IP address, port number, [client hostname FQDN], [server virtual name/port], ...). Yes, we could add some. But that's going to be a lot of work, and there's the potential for conflicts with Linux-PAM (hopefully not, but I've not looked). - last(1), w(1), ... should use the same DB as login apps, or PAM, are using. If we use PAM... then it's hard to tell which DB is in use! IMO it would be unacceptable for last(1) and friends to break, or not find all the relevant information, when using an alternative user login DB. - Some PAM apps don't call pam_close_session(3PAM) and pam_end(3PAM) in the same process, or even with the same PAM handle, as pam_open_session(3PAM). Or maybe the call pam_close_session(3PAM) with less than all privileges. We could get away with saying that all third-party apps that are broken in this way are... broken and that's too bad. But we have some right in Solaris that are similarly broken. The SunSSH sshd used to get this right, but recently it became one of these broken applications (for reasons that are not relevant here). The Solaris telnet and rlogin daemons are also similarly broken (unless auditing is enabled). Modules can sometimes work around this well enough, but it requires jumping through hoops. I've no idea if the module in question here does that. IMO it would be fine to ship the module, with suitable warnings in its manpage, but /etc/pam.conf should make no use of it. Except, perhaps, in the case of the gdm service, in which case GDM could skip using ConsoleKit directly (but I suspect that GDM will run into the "not enough PAM items" problem). Nico --
