pam_ck_connector.so is called for non-login sessions

The kerneloops package correctly creates the user as a system user,
so this seems to be a GDM issue.

I can't see what is different about the kernoops user that makes it
show up, is the only system user listed?

Thanks,

James

On one of my machines, the only interactive user is *not* displayed in the selection box. It sounds as if the criteria for user filtering need to be refined in both directions.

gdm uses ck-history to find recent users that had ck sessions. We currently
end up with ck sessions for some system users, so they can appear here, which
should probably be fixed independently.

gdm then parses this and removes some users based on a hard-coded exclude
list, which doesn't include a lot of system users.

It also filters users based on a minimum UID that is lower than the min UID
for non-system users, so if someone has a lot of system users they will show
up based on that.

Suggested fix:

  * Increase the min UID
  * As users from /etc/passwd are excluded by the checks before the exclude
     check, add them to the exclude hash so that they don't enter the list via
     ck.

Thanks,

James

Also, the ck-history code could not add users, but just update the frequency of
existing users, avoiding this in that manner as well.

Thanks,

James

It appears that the reason I saw no users was because some consolekit related thing was taking lots of time to process, blocking the list population. On a second boot, the list initially appeared unpopulated, but was populated with relevant users after about 5 seconds. (Point of interest: ck-history was still running and consuming lots of CPU for several seconds *after* login.)

This bug was fixed in the package gdm - 2.26.1-0ubuntu3

---------------
gdm (2.26.1-0ubuntu3) karmic; urgency=low

  * Add 03_hide_system_users.patch: Do not show system users in the "frequent
    users" list. (LP: #395281)
  * debian/rules: Call dh_installinit with --no-scripts, to avoid restarting
    gdm (and killing your X session) during upgrade. The prerm/postinst
    scripts already have code to reload gdm if appropriate. Unfortunately this
    doesn't help to fix the upgrade from 0ubuntu2, its prerm already kills it.
    (LP: #395302) This also fixes the "locks session and spawns a second X
    server" issue on upgrades from Jaunty. (LP: #395313)
  * Drop 16_correct_customconf_naming.patch: Upstream uses
    and installs /etc/gdm/custom.conf, so gdm also needs to read this. Add
    debian/gdm.preinst to migrate the old name to the new name on upgrades.
    (LP: #395861)
  * 02_dont_force_us_keyboard.patch: Don't return NULL in
    get_default_layout(), but return an empty string and explicitly check this
    when setting $GDM_KEYBOARD_LAYOUT. With NULL, gdm trips over an assertion
    check. (LP: #395595)

 -- Martin Pitt <email address hidden> Mon, 06 Jul 2009 16:04:25 +0200

I'm not sure to understand correctly of the information above so here is my question : is it possible to customise the user that should not be shown in karmic without changing their uid to a value lower than 1000 ?

I think I have the answer : this is the following debian bug http://debathena.mit.edu/trac/ticket/429

I can't seem to open/Confirm this for Natty only.

I suspect it's the same problem, for 2.32.0-0ubuntu1 in Natty.

My /etc/gdm/custom.conf is empty, aside from section headers and <<EOF

[greeter]

DefaultFace=

GlobalFaceDir=/usr/share/pixmaps/
EOF

My gdm.conf.dpkg-bak has "MinimalUID=1000" in it's [greeter] section, FWIW.

Daemon users showing up are rabbitmq (uid 133) and couchdb (uid 127).

$ ck-history --frequent
cmiller 279
rabbitmq 60
nobody 55
maryelle 34
gdm 33
couchdb 27
guest 3
root 1

This is really a bug in the libpam-ck-connector PAM integration. It shouldn't be in common-session, but in /etc/pam.d/login only.
/usr/share/pam-configs/consolekit already says "Session-Interactive-Only: yes", so pam-auth-update shoudln't put it in common-session in the first place (as this is also called for cron and the like)?

If pam-auth-update can't put stuff into /etc/pam.d/login, then we need to work around this in consolekit itself and filter out system users.

Let's not continue to hack around this in gdm any more, it's just wrong, and a waste of IO, cycles, and power to always run consolekit on every cron or at session.

8On Fri, Dec 10, 2010 at 03:27:36PM -0000, Martin Pitt wrote:
> This is really a bug in the libpam-ck-connector PAM integration. It shouldn't be in common-session, but in /etc/pam.d/login only.
> /usr/share/pam-configs/consolekit already says "Session-Interactive-Only:
> yes", so pam-auth-update shoudln't put it in common-session in the first
> place (as this is also called for cron and the like)?

No, common-session is the file for "interactive" services; "noninteractive"
services need to include common-session-noninteractive instead of
common-session, and any noninteractive service that is including
common-session is buggy.

> If pam-auth-update can't put stuff into /etc/pam.d/login

It does not, no. But that should be immaterial; if these extra entries are
coming from cron, that was fixed in karmic.

OTOH, if they're coming from an init script that's calling 'su', that's a
buggy init script; init scripts should use start-stop-daemon, not su.

Maybe login is the *only* service that pam_ck_connector should be applied
to for other reasons because the distinction between login and non-login
*interactive* sessions matters, but I don't think ck-history should be a
reason for that.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Steve,

thanks for the clarification. So it seems rabbitmq and couchdb are cases of using "su". I'm a bit undecided whether "login" should really be the only service for pam-ck. It's the main use case for e. g. giving you access to your sound card if you login through a VT, but it's also nice to get that if you do su - otheruser. Ideally we'd only count this as an user session if this actually called the login shell, but that's outside of PAM.

So I think the best course of action is to fix CK to ignore system users and also fix the couchdb/rabbitmq init scripts to not use su.

Also in my /etc/init.d are ejabberd and pgbouncer using "su".

It's far from uncommon to use su in startup scripts - even ones crafted by local sysadmins. I don't think defining 'su' to start a CK session is the right thing to do.

Case in point: I crafted a local upstart job to run a java rmiregistry on my machine, and I su-ed it because it has no need to run as root, and no user-changing capability of its own. Later, I started getting spurious "there is another user logged in" warnings when shutting down my computer. It took some considerable head-scratching before I realized the non-obvious linkage here, and then only because I had some small prior experience with CK oddities.

On Tue, Dec 14, 2010 at 01:22:22AM -0000, Max Bowsher wrote:
> It's far from uncommon to use su in startup scripts - even ones crafted
> by local sysadmins. I don't think defining 'su' to start a CK session is
> the right thing to do.

su *is* the wrong tool to use for starting services, because su *is* defined
to start PAM sessions. pam_ck_connector is not the only PAM module that may
get called by su that shouldn't be called when starting a service - such as
pam_limits, to pick one commented out example from /etc/pam.d/su itself.

That local sysadmins *may* make uninformed choices when writing their init
scripts doesn't change the fact that you don't want to start a PAM session
from an init script, and the adverse interactions with pam_ck_connect are
only one symptom of this.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

that's still an issue, see bug #699930

This bug affects 11.10 and rabbitmq. The computer will not shutdown via lightdm or gnome session because lightdm thinks rabbitmq is still running. It's worth noting I don't use the ubuntu provided rabbitmq packages. Instead I use the packages from rabbitmq.com . I haven't tested this issue with the ubuntu rabbitmq package.

Steve Langasek said:
> su *is* the wrong tool to use for starting services, because su *is* defined
> to start PAM sessions.

Gosh, I wish I'd seen that a year ago :)

I hope this is a reasonable place to ask the following question:

So if I can't use su, what can I use? I want to start the rabbit process as the "rabbitmq" user, and Erlang programs can't easily setuid(3). I'm not aware of an alternative to su, but I could well be ignorant.

Gah, I can't read. start-stop-daemon.

Simon MacMullen [2011-12-05 10:58 -0000]:
> So if I can't use su, what can I use? I want to start the rabbit process
> as the "rabbitmq" user, and Erlang programs can't easily setuid(3). I'm
> not aware of an alternative to su, but I could well be ignorant.

In the Debian world we use start-stop-daemon with the -c/-g options,
see the manpage.

Thanks, Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)