This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 228110 - Login managers needs to use ConsoleKit if apps in the session needs HAL
Login managers needs to use ConsoleKit if apps in the session needs HAL
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: distribution (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Bill Nottingham
: Reopened, Tracking
: 230958 (view as bug list)
Depends On: 228079 228111 229172 233183 237621
Blocks:
  Show dependency treegraph
 
Reported: 2007-02-09 20:14 EST by David Zeuthen
Modified: 2014-03-16 23:05 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-02-26 09:51:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description David Zeuthen 2007-02-09 20:14:35 EST
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.
Comment 1 Patrice Dumas 2007-02-10 04:17:36 EST
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?
Comment 2 Bill Nottingham 2007-02-12 10:46:29 EST
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.
Comment 3 Patrice Dumas 2007-02-12 11:04:02 EST
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.
Comment 4 David Zeuthen 2007-02-12 11:49:30 EST
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!
Comment 5 jmccann 2007-02-12 12:36:46 EST
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.
Comment 6 Patrice Dumas 2007-02-13 09:18:10 EST
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.
Comment 7 David Zeuthen 2007-02-19 23:44:16 EST
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.
Comment 8 Karel Zak 2007-02-20 08:37:22 EST
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?
Comment 9 David Zeuthen 2007-02-20 23:46:38 EST
(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 :-)
Comment 10 Karel Zak 2007-02-21 03:43:35 EST
(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?

Comment 11 David Zeuthen 2007-02-22 02:14:58 EST
(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.
Comment 12 Tomas Mraz 2007-02-22 03:14:38 EST
> 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.
Comment 13 Karel Zak 2007-02-22 04:31:04 EST
> 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?

 

Comment 14 David Zeuthen 2007-02-22 12:20:47 EST
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.)
Comment 15 David Zeuthen 2007-02-28 00:47:16 EST
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.
Comment 16 David Zeuthen 2007-03-03 15:54:40 EST
FYI, ConsoleKit-libs have been in Rawhide for a few days now.
Comment 17 David Zeuthen 2007-03-04 22:46:30 EST
*** Bug 230958 has been marked as a duplicate of this bug. ***
Comment 18 David Zeuthen 2007-05-01 12:40:48 EDT
Looks like we're only missing xdm and wdm now...
Comment 19 Jeremy Katz 2007-05-18 17:33:11 EDT
We got the majors here; dropping this down to target for the remaining pieces
Comment 20 Matěj Cepl 2008-05-13 06:18:00 EDT
This shouldn't be closed unless all its blockers are fixed. Retargetting.
Comment 21 Bug Zapper 2008-05-13 22:36:10 EDT
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
Comment 22 Bug Zapper 2009-06-09 18:27:00 EDT
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
Comment 23 Bug Zapper 2009-07-14 13:12:47 EDT
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.
Comment 24 Patrice Dumas 2009-10-22 15:48:24 EDT
Reopening, xdm is certainly not fixed. wdm is orphaned and deprecated.
Comment 26 Bill Nottingham 2014-02-26 09:51:58 EST
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.

Note You need to log in before you can comment on or make changes to this bug.