Ticket #886 (closed defect: workaround)

Opened 13 years ago

Last modified 11 years ago

Unlocking screen messes with zwgc's auth

Reported by: cfox Owned by:
Priority: normal Milestone: The Distant Future
Component: -- Keywords:
Cc: Fixed in version:
Upstream bug:

Description

When I type my password into gnome-screensaver, my running zwgc loses
the ability to authenticate incoming zephyrs (can be fixed with 'zctl
load /dev/null')

My .bash_environment messes with $KRB5CCNAME which may confound matters;
however, my running gnome-screensaver has the same KRB5CCNAME value in
its environment.

(Highly reproduceable on my workstation, red-herring.mit.edu which is 32
bit lucid.)

Change History

comment:1 Changed 13 years ago by geofft

I can reproduce this without messing with KRB5CCNAME at all -- just run zwgc, lock the screen, and unlock it.

comment:2 Changed 12 years ago by jdreed

I'm not entirely sure we can fix this, but some terrible ideas come to mind:

  • zwgc could learn about DBus and listen for the various events when the screen is locked/unlocked
  • we could play stupid tricks with gnome-screensaver's pam config, and use pam_env to play with KRB5CCNAME (or PAMKRB5CCNAME?) so that it doesn't scribble over the "real" ticket cache. Possibly doing the latter only in response to ${GNOME_SCREENSAVER_NO_RENEW+set} or something.

comment:3 follow-up: ↓ 4 Changed 12 years ago by kcr

Is it impossible to run a shell command on unlock?

(Having zwgc listen to dbus is something I've thought would be a good idea for a while.)

comment:4 in reply to: ↑ 3 Changed 12 years ago by jdreed

Replying to kcr:

Is it impossible to run a shell command on unlock?

No. Nor even on lock. Unless we want to revisit xscreensaver (I bet we don't).

comment:5 follow-up: ↓ 6 Changed 12 years ago by jdreed

I'm now seriously considering punting gnome-screensaver by defaulting and revisiting xscreensaver. That having been said, did anyone actually look at gnome-screensaver's PAM config? Does pam_krb5 have a "Just verify the password and don't do anything else" option? Or would we have to play games with pam_env?

comment:6 in reply to: ↑ 5 Changed 12 years ago by geofft

Replying to jdreed:

I'm now seriously considering punting gnome-screensaver by defaulting and revisiting xscreensaver.

I think xscreensaver does not communicate with the rest of the session as well as gnome-screensaver, so this may break other things.

Does pam_krb5 have a "Just verify the password and don't do anything else" option?

no_ccache. (retain_after_close also looks plausibly useful.)

Also, instead of playing games with KRB5CCNAME, just use ccache_dir.

 http://manpages.ubuntu.com/manpages/precise/en/man5/pam_krb5.5.html

comment:7 Changed 11 years ago by jdreed

  • Status changed from new to closed
  • Resolution set to workaround

I poked at this today. It's not really fixable, because gnome-screensaver's PAM config uses common-auth, and there's no good way to conditionally add no_ccache in certain cases. I also looked at pam_exec, but of course that execs during the PAM stack, _before_ the ccache has been overwritten. The actual bug here is "gnome-screensaver is different from our customized xscreensaver", and I'm not convinced we want to write a PAM module for that. I have documented the manual process at:  http://kb.mit.edu/confluence/x/XSAYCQ (it's a wiki, if it's wrong, update it). Someone who feels strongly is welcome to open an upstream Zephyr bug about it learning to speak DBus and reloading subs upon unlock.

Note: See TracTickets for help on using tickets.