Do not create CK sessions for cron and other system sessions

Thank you for your bug report, not confirming the issue though. Could you run ck-list-sessions and copy the log to the bug?

The reason is that cron opens a PAM session, which causes libpam-ck-connector to register a session for it.

So either cron shouldn't get a CK session in the first place (which would make sense IMHO), or at least such sessions shouldn't count as "multiple users".

Hi Martin,

Do you suggest that pam_ck_connector gets removed from common-session, and
gets placed in to those sessions that need it?

Another alternative I could think of is that the common-session entry is changed to
add an option to specify that the CK session should be degenerate, and not count
for decisions like whether to allow shutdown, and then add an entry for those session
types that need a full session have another entry without the option. I'm not sure
why a session should be added for most things though.

Thanks,

James

James,

no, I intend to keep it in common-session, after discussion with upstream and Steve Langasek. Putting it into "login" and "gdm" would actually have been my first choice, but we can't auto-configure pam-ck-connector in those. Also, the PAM configuration framework Steve was writing only supports the non-conffiles for good reason.

I think we should just fix pam-ck-connector to not create a CK session for "those" PAM sessions. This might be "system user", or "no associated terminal", I'm not quite sure yet.

On Wed, 2008-10-29 at 16:07 +0000, Martin Pitt wrote:
> James,
>
> no, I intend to keep it in common-session, after discussion with
> upstream and Steve Langasek. Putting it into "login" and "gdm" would
> actually have been my first choice, but we can't auto-configure pam-ck-
> connector in those. Also, the PAM configuration framework Steve was
> writing only supports the non-conffiles for good reason.
>
> I think we should just fix pam-ck-connector to not create a CK session
> for "those" PAM sessions. This might be "system user", or "no associated
> terminal", I'm not quite sure yet.

Cool, thanks for looking at this. Let me know if there is anything I can
help with.

Thanks,

James

Is a fix expected out anytime soon? I know there are bigger problems in the world, but it's unfun to type a password whenever I want to shut down the PC.

i also experience this. I mysteriously started to get prompted for a root password each time I wanted to log out. I suspect it might be a cron job that I added a few days ago. Running w in terminal gives

richard@gR0iDin:~$ w
 00:45:29 up 9:56, 2 users, load average: 2.01, 1.97, 1.68
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
richard tty7 :0 14:49 9:56 28:25m 3.66s /usr/bin/gnome-
richard pts/0 :0.0 00:39 0.00s 0.50s 0.04s w

My work around is to go into system > administration > authentication, then org > freedesktop > hal > powermanagement > shut down system with multiple users and changed from needed authorization to simply "yes".

on a side note, the dialogue that makes me put in my root password has weird wording. screenshot attached

Just for the record, I've encountered this when I installed adeona (http://adeona.cs.washington.edu/index.html) on two different laptops. It doesn't happen on my desktop, which I upgraded from hardy with adeona already installed.

Martin,

Is http://bazaar.launchpad.net/~james-w/ubuntu/karmic/consolekit/no-system-users/revision/32
what you were thinking of?

I don't fully understand the constraints, so I don't know if this would be the
correct change.

Thanks,

James

Hello James,

James Westby [2009-07-03 22:01 -0000]:
> Is
> http://bazaar.launchpad.net/~james-w/ubuntu/karmic/consolekit/no-system-users/revision/32
> what you were thinking of?

I haven't tested it, but it seems like a valid bandaid. Should be
cleaned with upstream, of course. You should test against < 500,
though. [1]

Actually I rather thought about making cron sessions not start
consolekit sessions in the first place, since otherwise you'd still
have that problem with user cronjobs, wouldn't you?

[1] http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/uidrange.html

> I haven't tested it, but it seems like a valid bandaid. Should be
> cleaned with upstream, of course. You should test against < 500,
> though. [1]

Ah, thanks for the pointer.

> Actually I rather thought about making cron sessions not start
> consolekit sessions in the first place, since otherwise you'd still
> have that problem with user cronjobs, wouldn't you?

That would certainly be better I think. I'm just not sure how to do it.

My understanding is that currently we have

  cron -> pam -> pam-ck-connector in common-session -> ck session

We can't have cron bypass pam, so we either need it to miss out pam-ck-connector,
or pam-ck-connector to ignore cron. My PAM knowledge is too weak to know
if either of these is possible or how we would go about it.

Thanks,

James

Talking to Steve this is something that should be fixed with an
interactive/non-interactive split in PAM common files.

We can fix some of the GDM issues that this causes, but the shutdown
issue isn't really going to go away until that split happens, though we could
perhaps apply my suggested patch to lessen the impact.

Thanks,

James

So what we really need to do here is to not create CK sessions for every system session like cron. It creates not only this bug, but has a couple of other side effects, like making system users appear in gdm, and showing them as "most popular login" in the gdm user list.

I discussed this with Steve Langasek, and he said that he plans to split "common-session", so that we will get a new /etc/pam.d/common-session-interactive. Then libpam-ck-connector could register there instead of to common-session.

This bug was fixed in the package pam - 1.0.1-11ubuntu1

---------------
pam (1.0.1-11ubuntu1) karmic; urgency=low

  * Merge from Debian, remaining changes:
    - debian/libpam-modules.postinst: Add PATH to /etc/environment if it's not
      present there or in /etc/security/pam_env.conf. (should send to Debian).
    - debian/libpam0g.postinst: only ask questions during update-manager when
      there are non-default services running.
    - debian/patches-applied/series: Ubuntu patches are as below ...
    - debian/patches-applied/ubuntu-fix_standard_types: Use standard u_int8_t
      type rather than __u8.
    - debian/patches-applied/ubuntu-no-error-if-missingok: add a new, magic
      module option 'missingok' which will suppress logging of errors by
      libpam if the module is not found.
    - debian/patches-applied/ubuntu-regression_fix_securetty: prompt for
      password on bad username.
    - debian/patches-applied/ubuntu-rlimit_nice_correction: Explicitly
      initialise RLIMIT_NICE rather than relying on the kernel limits.
    - debian/patches-applied/ubuntu-user_defined_environment: Look at
      ~/.pam_environment too, with the same format as
      /etc/security/pam_env.conf. (Originally patch 100; converted to quilt.)
    - Change Vcs-Bzr to point at the Ubuntu branch.
    - debian/local/common-password, debian/pam-configs/unix: switch from
      "md5" to "sha512" as password crypt default.
    - Make libpam-modules depend on base-files (>= 5.0.0ubuntu6), to ensure
      run-parts does the right thing in /etc/update-motd.d.
    - debian/patches-applied/pam_motd-legal-notice: display the contents of
      /etc/legal once, then set a flag in the user's homedir to prevent showing
      it again.
  * debian/local/pam-auth-update: prune some more md5sums from intrepid
    pre-release versions, reducing the Ubuntu delta some
  * debian/local/common-{auth,account,password}.md5sums: include the
    Ubuntu-specific intrepid,jaunty md5sums for use during the
    common-session-noninteractive upgrade.

pam (1.0.1-11) unstable; urgency=low

  * debian/libpam-runtime.postinst: bump the --force version check to
    1.0.1-11, to allow for a new common-session-noninteractive config file;
    and include md5sum checking logic that will work the same with old
    unmanaged and new managed /etc/pam.d/common-* files.
  * debian/local/common-{auth,account,session,password}.md5sums: document
    the known md5sums for the new managed files.
  * debian/local/common-session-noninteractive{,.md5sums},
    debian/local/pam-auth-update: split out a session-noninteractive include
    file, so that we can at last distinguish between interactive and
    non-interactive PAM sessions at a policy level. Closes: #169930,
    LP: #287715.
  * debian/local/pam-auth-update: prune md5sums for unsupported upgrade
    paths (intrepid pre-release -> karmic/squeeze)
  * Clean up the PAM mini-policy, which hasn't been touched in a number of
    years and was looking a bit crufty
  * debian/libpam-runtime.templates: correctly tag the URL as a
    non-translatable string.
  * Updated debconf translations:
    - Swedish, thanks to Martin Bagge <email address hidden> (close...

This bug was fixed in the package consolekit - 0.3.1-0ubuntu2

---------------
consolekit (0.3.1-0ubuntu2) karmic; urgency=low

  * debian/libpam-ck-connector.pam-auth-update: mark this module as applying
    only to interactive sessions. LP: #287715.

 -- Steve Langasek <email address hidden> Mon, 24 Aug 2009 04:32:10 +0000

Excellent, thanks Steve.

James

I have recently done a fresh install of Karmic, and I'm getting this bug. I have the latest updates via update manager, but it still asks me for a password when I shutdown.

I have an upgraded Jaunty to Karmic - all updates - getting this bug:

Output of ck-list-sessions:

Session7:
 unix-user = '1000'
 realname = 'Musther'
 seat = 'Seat1'
 session-type = ''
 active = TRUE
 x11-display = ':0'
 x11-display-device = '/dev/tty7'
 display-device = ''
 remote-host-name = ''
 is-local = TRUE
 on-since = '2009-11-06T09:24:15.631854Z'
 login-session-id = '4294967295'
Session1:
 unix-user = '113'
 realname = '(null)'
 seat = 'Seat1'
 session-type = ''
 active = FALSE
 x11-display = ''
 x11-display-device = ''
 display-device = '/dev/???'
 remote-host-name = ''
 is-local = TRUE
 on-since = '2009-11-06T09:11:33.149377Z'
 login-session-id = '4294967295'

This system session doesn't appear to be from cron, from the timestamp that session was open for at least 13 minutes. What is user 113 on your system?

I get something similar, but with ID 114, and it turns out it's mythtv.

J, can you post the full ck-list-sessions output for your mythtv case?

Jonathan, are you also running mythtv on your system where you see this problem?

Session3:
 unix-user = '114'
 realname = '(null)'
 seat = 'Seat1'
 session-type = ''
 active = FALSE
 x11-display = ''
 x11-display-device = ''
 display-device = '/dev/???'
 remote-host-name = ''
 is-local = TRUE
 on-since = '2009-11-06T18:36:58.002748Z'
 login-session-id = ''
Session6:
 unix-user = '1000'
 realname = 'j'
 seat = 'Seat1'
 session-type = ''
 active = TRUE
 x11-display = ':0'
 x11-display-device = '/dev/tty7'
 display-device = ''
 remote-host-name = ''
 is-local = TRUE
 on-since = '2009-11-06T19:24:41.310358Z'
 login-session-id = ''

I'm getting the same problem and am running MythTV. Problem occurred after upgrade to Karmic.

Output of ck-list-sessions:

Session1:
 unix-user = '114'
 realname = '(null)'
 seat = 'Seat1'
 session-type = ''
 active = FALSE
 x11-display = ''
 x11-display-device = ''
 display-device = '/dev/???'
 remote-host-name = ''
 is-local = TRUE
 on-since = '2009-11-11T09:06:43.277769Z'
 login-session-id = ''
Session2:
 unix-user = '1000'
 realname = 'Paul'
 seat = 'Seat1'
 session-type = ''
 active = TRUE
 x11-display = ':0'
 x11-display-device = '/dev/tty7'
 display-device = ''
 remote-host-name = ''
 is-local = TRUE
 on-since = '2009-11-11T09:06:47.536543Z'
 login-session-id = ''

Can't find a user with id 114 though. id outputs:

uid=1000(paul) gid=1000(paul) groups=4(adm),20(dialout),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),107(fuse),109(lpadmin),115(admin),125(sambashare),127(mythtv),1000(paul),1001(remote)

127 is the group id, but 114 is the user id: cat /etc/passwd

Thanks. Yup, it's mythtv holding the other session for me too.

The problem with mythtv is filed as bug #445953.

I see, same result, different bug source. Have removed that this bug affects me. Thanks.