Description of problem: This is a tracking bug for login managers. In order to make fast-user switching work, login managers now need to use ConsoleKit. This is done for gdm already and it's explained here http://bugzilla.gnome.org/show_bug.cgi?id=365375 how this is done. See also http://fedoraproject.org/wiki/Desktop/FastUserSwitching for more information about ConsoleKit.
Doing that in the display manager (in fedora) seems to be plain wrong to me, this is to be done on the pam level. Maybe the window manager could have a duplication of the code, for platforms where there is no pam or pam don't support ConsoleKit, but on fedora (and linux in general) the pam way is the right way. This way, it is available in all display managers use pam, and the administrator (or the vendor) may decide which pam enabled services are ConsoleKit seats. Couldn't the ConsoleKit people come with a pam_ConsoleKit module?
pam only runs at session start and session exit - there's no hooks in pam where you could use it for notification of when sessions become active or inactive.
I don't get it. Isn't the missing ConsoleKit code a code that enable the console-kit daemon to be notified about session opening (and maybe closing) and that sets up the environment such that call to HAL succeed? Sessions become active or inactive when users log in and out? Am I missing something? If there is really something specific such that it cannot be handled at the pam level, then there is certainly a need for a ConsoleKit API that hides all the DBus and implementation details complexity. Maybe something like that already exists? I don't see any ConsoleKit-devel however.
Jon, I remember we talked about doing a PAM-ConsoleKit thing but you had a number of arguments against this and hence why we ended up patching gdm. Care to elaborate? Thanks!
Hi, I experimented with using PAM in one of the early versions of CK (then ConsoleManager) for session creation. Some of the reasons why it didn't work are listed here: http://live.gnome.org/BetterPowerManager Not listed there but also important is the inability to have a D-Bus connection to track. Using PAM is also seriously limiting both in terms of the rules a module has to follow due to the process space etc and the very limited API available to a module. Then there is also the fact that just about everything lies to PAM about the value of TTY. If there are any specific questions I'll be happy to respond.
In fact I didn't said that pam should be used to get the information about seats, but that a specific pam module should be done that talks with dbus and sets the environment variable. It would certainly be a simple account module. Otherwise said I think that the code in gdm relating with ck session opening and closing should better be in a pam account module.
Btw the patch in bug 229172 comment 7 contains a patch with some code that will make this almost trivial to add to any login manager. It only requires D-Bus and also handles OOM etc. etc. I've put that patch in the public domain so you can with it what you want.
Please, can we collect all items why ConsoleKit can't be in PAM? I've found (http://live.gnome.org/BetterPowerManager): - Shouldn't trust passed in PAM_TTY value - PAM_TTY value isn't always a tty but sometimes a $DISPLAY - sometimes PAM_TTY is bogus (eg. sshd uses "ssh") - Can't reliably get a pid for session since PAM module isn't always run by that process but by a helper/proxy or parent - inability to have a D-Bus connection to track (can anyone explain this?) I'm not 100% sure if new API is better solution that fix/extend PAM. The things like pam_set_item() are almost unrestricted. IMHO add there new items like PID, REAL_TTY (if PAM_TTY suck) and others things is less ugly that huge patches with dbus code to all login-like programs. Tom, what do you think? Is possible to improve PAM (extend API) and provide more information about "where" and "what" for PAM modules?
(In reply to comment #8) > inability to have a D-Bus connection to track (can anyone explain this?) So the main thing about D-Bus connection tracking is that ConsoleKit can notice if the process (e.g. the login manager such as gdm, /bin/login, kdm and so on) registering with ConsoleKit (e.g. calls OpenSessionWithParameters()) exits. This is possible because that process keeps a connection (UNIX socket) open to the system message bus daemon and once the process exits the bus will announce that the unique connection name went away. ConsoleKit listens for such announcements and can look and see that the unique connection who invoked OpenSessionWithParameters() now went away. This means that ConsoleKit can close that session. This is not possible with PAM. We cannot keep the connection to the system message bus daemon open because that would violate how a PAM module works. So we would have to change ConsoleKit in a way such as to rely on CloseSession() being called. In other words, with PAM you specifically have to run pam_end()... and gods know what happens if some random PAM module crashes the process before we get to call into ConsoleKit to close the session. What happens if the login manager itself crashes? As ConsoleKit is being used - to trigger granting of ACL's - plays a part in whether callers are privileged to e.g. mount storage devices over D-Bus - other highly sensitive things you really really want to be able to take advantage of D-Bus connection tracking to guarantee that no stale session are around. Sure, it's easy to a) adapt the code in bug 229172 comment 7 to be a PAM module. That does not mean it should be a PAM module. Also, I'd be worried that all the other apps using PAM gets this wrong and suddenly various session objects appear on ConsoleKit resulting in privileges granted where they shouldn't. b) make ConsoleKit stop tracking connections because PAM enforces us to. > I'm not 100% sure if new API is better solution that fix/extend > PAM. The things like pam_set_item() are almost unrestricted. > IMHO add there new items like PID, REAL_TTY (if PAM_TTY suck) > and others things is less ugly that Realistically, this only involves patching /bin/login, gdm, kdm + potentially other graphical login managers such as wdm. For the record the gdm patch is already committed upstream. I can't speak for the kdm guys but since the rest of KDE is support HAL well I'd bet that such a patch has a good chance of going upstream if they want KDE to support things like f-u-s / multi-seat and benefit from HAL support. Btw, I'm not sure relying on patches for "fixing" PAM is such a good idea as other distros / OS'es will be using this stuff too and asking them to patch a *framework* like PAM that many many many programs use is perhaps more than asking them to patch the single /bin/login program. Of course, should PAM be fixed to do all this (including connection tracking) we could switch to it for ConsoleKit. > huge patches with dbus > code to all login-like programs. I wouldn't exactly call it a huge patch - it's all hidden behind a neat little class called CKConnector :-)
(In reply to comment #9) > the system message bus daemon and once the process exits the bus will announce > that the unique connection name went away. > > ConsoleKit listens for such announcements and can look and see that the unique > connection who invoked OpenSessionWithParameters() now went away. This means > that ConsoleKit can close that session. > > This is not possible with PAM. > > We cannot keep the connection to the system message bus daemon open because that > would violate how a PAM module works. So we would have to change ConsoleKit in a > way such as to rely on CloseSession() being called. In other words, with PAM you > specifically have to run pam_end()... and gods know what happens if some random > PAM module crashes the process before we get to call into ConsoleKit to close > the session. What happens if the login manager itself crashes? Crash = bug. You will see more and more problems if a PAM session is not closed correctly. I don't think that we should try to resolve it with ConsoleKit. > Sure, it's easy to > > a) adapt the code in bug 229172 comment 7 to be a PAM module. Firstly -- if you want to use d-bus directly (without PAM) you should move the consolekit code to shared library. I think we don't want to maintain same code in multiple places. > That does not mean it should be a PAM module. Also, I'd be I think in applications where PAM won't work correctly you can directly use something like lilbconsolekit. The PAM could be optional. > worried that all the other apps using PAM gets this wrong The set of PAM applications with ConsoleKit support is possible define very exactly. We can use the PAM module really for well defined group of login-like programs. BTW, what remote access to system?
(In reply to comment #10) > Crash = bug. You will see more and more problems if a PAM session is not closed > correctly. I don't think that we should try to resolve it with ConsoleKit. Wait. So you're telling me that you're fine with the status quo whereby device files are still owned by a user because gdm crashed and the PAM session is not closed? Because this bug is in our distro *today* and the workaround (which sometimes don't work - just try for yourself) is to respawn gdm and run some band-aid code to close sessions. This is exactly the situation we want to avoid. Keep in mind that *any* PAM module can crash your application. Heck, they run in your address space so essentially all bets are off as soon as you've run a single line of code from the PAM module. And since PAM is extensible any user can add his own PAM modules as he pleases. So I don't think we want to include all these PAM modules in the security path for managing permissions of device files. See also http://lists.freedesktop.org/archives/hal/2007-February/007180.html for some discussion on how we avoid this with ConsoleKit / HAL. (The only bit missing is a paranoid parachute to remove all ACL's should HAL decide to crash. We already remove all ACL's if ConsoleKit crashes.). Managing ACL's via CK/HAL is not a panacea either, but I'd say it's an improvement both functionality- and security-wise. > Firstly -- if you want to use d-bus directly (without PAM) you should move the > consolekit code to shared library. I think we don't want to maintain same code > in multiple places. I'm fine with providing /lib/libcktracker.so in a ConsoleKit-libs package for this kind of thing. As a matter of fact, exactly the same code is needed in xinit anyway. > I think in applications where PAM won't work correctly you can directly use > something like lilbconsolekit. The PAM could be optional. Again, the apps we're talking about are - /bin/login - gdm, kdm, wdm, etc. - xinit Clearly xinit don't use PAM. > > worried that all the other apps using PAM gets this wrong > > The set of PAM applications with ConsoleKit support is possible define very > exactly. We can use the PAM module really for well defined group of login-like > programs. The point is really that PAM is inadequate for this kind of thing. Heck, we could have written the PAM module + patch to CK to not track disconnections already, but the point is really that we don't want to put all the PAM modules loaded into the address space of the login manager into the security path. > BTW, what remote access to system? We haven't granted remote users access to devices in the past. It might be interesting for thin-client / LTSP / SunRay kind of stuff but I think such clients will login to the system via gdm or similar where we can get a lot more context than e.g. via ssh. Still, granting access to devices is something where we need to be a lot more careful than relying on a PAM session to be closed.
> So the main thing about D-Bus connection tracking is that ConsoleKit can notice > if the process (e.g. the login manager such as gdm, /bin/login, kdm and so on) > registering with ConsoleKit (e.g. calls OpenSessionWithParameters()) exits. > > This is possible because that process keeps a connection (UNIX socket) open to > the system message bus daemon and once the process exits the bus will announce > that the unique connection name went away. > > ConsoleKit listens for such announcements and can look and see that the unique > connection who invoked OpenSessionWithParameters() now went away. This means > that ConsoleKit can close that session. > > This is not possible with PAM. > > We cannot keep the connection to the system message bus daemon open because that > would violate how a PAM module works. So we would have to change ConsoleKit in a > way such as to rely on CloseSession() being called. In other words, with PAM you > specifically have to run pam_end()... and gods know what happens if some random > PAM module crashes the process before we get to call into ConsoleKit to close > the session. What happens if the login manager itself crashes? This is a nonsense, if you want to keep a file/socket descriptor open within an application (login/gdm... whatever) you can do it within a PAM module called from this application as well. It is not perfect from the aesthetics point of view but there is no problem with doing it. Of course the descriptor must be fcntl-ed with FD_CLOEXEC so it is automatically closed when the child process (user's shell) is execed. It seems to me you're somehow biased against using PAM without really good arguments as to why. More comments: > - Shouldn't trust passed in PAM_TTY value Why? It depends purely on the application which calls PAM to set it correctly. How it differs from not calling ConsoleKit correctly? > - PAM_TTY value isn't always a tty but sometimes a $DISPLAY Again - depends on the application but it is really easy to distinguish tty from DISPLAY. > - sometimes PAM_TTY is bogus (eg. sshd uses "ssh") This is true only for some special cases not really relevant to local user login. > - Can't reliably get a pid for session since PAM module isn't always run by that process but by a helper/proxy or parent If correctly implemented the PAM session calls must be called by a direct parent of a process which will later become a shell running the user's session. Again if there are some problems with the way applications call PAM which would make a theoretical ConsoleKit module to not work correctly the applications should be fixed.
> Keep in mind that *any* PAM module can crash your application. Heck, they run Yes. And kernel, glibc, and many others things can crash my application. How do you want to avoid this thing? This is nonsense -- the problem is not PAM, but how correctly detect that the session (login manager) doesn't exist. We should talk about this thing. The PAM is only one of piece of mosaic. > I'm fine with providing /lib/libcktracker.so in a ConsoleKit-libs package for > this kind of thing. Thanks. I'll be happy with this library if we will decide to use CK directly. This is the way how I can support CK in upstream code too. > Still, granting access to devices is something where we need to be a lot more > careful than relying on a PAM session to be closed. What do you think about Tom's idea with FD_CLOEXEC?
OK, let's try to look at what we're discussing. We're discussing whether /bin/login should poke CK via a PAM module or directly. It's essentially whether the code should be in the main /bin/login binary or a PAM module. Let's look at implications for using a PAM module - It would only be used by /bin/login anyway since things like gdm, kdm, wdm or whatever cannot use the PAM_TTY value passed in because this refers to the X display e.g. ":1" not "/dev/tty7". This is because the X server opens up a new VT. So, optionally the PAM module could ignore PAM_TTY if PAM_CKCONNECTOR_TTY is set. Heck, if they do this, they might as well link with the CKConnector library themselves. - But since it's a PAM module people maintaining login managers like wdm in all distros that use ConsoleKit will try to use it anyway for their own favourite display manager like wdm or whatever. Even if we had PAM_CKCONNECTOR_TTY they would presume it just worked and only later realize they would need to patch source code. - We would need to add the hack of keeping the connection to the system bus open - "not perfect from the aesthetics point of view" to quote our PAM package maintainer. Summary: I'd like to avoid a PAM module that a) is only usable for /bin/login; b) is only going to be used for /bin/login. The patch for /bin/login I presented in the other bug is not intrusive I think especially not if we have ConsoleKit-libs providing /lib/libckconnector.so. A PAM module will just create more confusion because it creates the illusion that it will just work with anything. I'd like to get some resolution on this. (For the record all sockets opened by libdbus are using FD_CLOEXEC.)
Hi again, So it seems most people want a PAM module so I did this http://lists.freedesktop.org/archives/hal/2007-February/007363.html Applications can set PAM environment variables [1] to override the tty and X11 display values. Note that ConsoleKit will do checking so setting them to whatever you want won't do any good. Well, notably login(1) doesn't need to do anything but include "session optional pam_ck_connector.so". But that's discussed in bug 229172. I'll do a build of CK with this patch tomorrow such that we'll get a ConsoleKit-libs package. Thoughts? [1] : Quoting from the man page: The pam_ck_connector PAM module registers a login session with the system-wide ConsoleKit daemon. This PAM module should be used with caution; only local login managers such as login(1) should use this. Since the ConsoleKit daemon can accept both an tty and an X11 display the normal parameters set by PAM are not always useful. An application can therefore override these with the PAM environment variables CKCON_TTY and CHCON_X11_DISPLAY (the application should remember to unset these before starting the login session). Also note that the ConsoleKit daemon may reject registration attempts if the given set of data are inconsistent with each other. More more information, see the ConsoleKit documentation on the OpenSessionWithParameters() method call on the org.freedesktop.ConsoleKit.Manager D-Bus interface. If registration with the ConsoleKit daemon succeeds, this PAM module will set the environment variable XDG_SESSION_COOKIE which is used to defined membership of a login session. This PAM module has the side effect that it creates a connection to the system message bus that is kept open until the session ends. This is used by the ConsoleKit daemon to track the life-cycle of the session and, as such, should the login manager crash, the session will be properly unregistered.
FYI, ConsoleKit-libs have been in Rawhide for a few days now.
*** Bug 230958 has been marked as a duplicate of this bug. ***
Looks like we're only missing xdm and wdm now...
We got the majors here; dropping this down to target for the remaining pieces
This shouldn't be closed unless all its blockers are fixed. Retargetting.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
Reopening, xdm is certainly not fixed. wdm is orphaned and deprecated.
Subject: Login managers need to use <obsolete thing> if apps in the session need <other obsolete thing>. As written, not sure there's any point to keeping this open.