gnome-keyring-daemon fails to start as it can't get capabilities

I wouldn't advise using setuid here. This will probably change the permissions of the files in your home directory, and cause problems when the actual issue is fixed and there's an update, where gnome-keyring won't be able to read your keyring files.

James, I can't reproduce this. Any ideas on how to reproduce?
Is this after you set up/copy over some keys?

Marc Just a fresh install from from tuesday's image had the same issue and this temp work around fixed it.

I'll try a more current iso and see if it is still the same latter

OK, I've successfully reproduced this issue by installing a clean i386 VM with the 2011-07-21 live cd.

Looks like gnome-keyring now needs file capabilities. The postinst sets capabilities, but I suspect the "setcap" utility isn't installed when gnome-keyring gets installed on new installations.

Workaround:
sudo setcap CAP_IPC_LOCK=ep /usr/bin/gnome-keyring-daemon

Also, it should be able to run even if the filesystem capabilities aren't set, but for some reason, it's getting CAPNG_FAIL...needs investigation...

Actually, I was looking at upstream git...our version is too old. We should update to 3.1.4 to get these two commits:
http://git.gnome.org/browse/gnome-keyring/commit/daemon/gkd-capability.c?id=ad67edd5fb25fca974f10f568c31a2316d728b79
http://git.gnome.org/browse/gnome-keyring/commit/daemon/gkd-capability.c?id=11a5d410d9d2c9006d78cff05ee42759cc7731b1

will those commit fix the issue or just workaround the fact that the setcap call didn't happen for some reason?

oh, also Chrisccoulson is working on the gnome-keyring update, it's just taking some time because it requires a new depends to be packaged first

The commits will let gnome-keyring start anyway, even if setcap didn't work, by using insecure memory. Ideally, we'd also have setcap working.

So...the livecd filesystem doesn't seem to support file caps.
We probably need ubiquity to manually set file caps on this binary after copying it to the hard disk during installation.

from irc discussion:

<ev> so the package in question should carry a script in /usr/lib/ubiquity/target-config to set things up properly
 see jockey for an example

This bug was fixed in the package gnome-keyring - 3.1.1-0ubuntu3

---------------
gnome-keyring (3.1.1-0ubuntu3) oneiric; urgency=low

  * debian/patches/99git_fs_caps_11a5d41.patch: cherry-pick patch from git:
    improve checks for FS capabilities.
  * debian/patches/99git_ipc_lock_caps_ad67edd.patch: cherry-pick patch from
    git: accept to run if ipc_lock capability is not available. (LP: #813755)
  * debian/gnome-keyring.ubiquity: apply capabilities at the end of the
    ubiquity process to make sure new installs have gnome-keyring-daemon with
    cap_ipc_lock+ep.
  * debian/rules: install ubiquity target-config script.
 -- Mathieu Trudel-Lapierre <email address hidden> Tue, 02 Aug 2011 15:42:31 -0400

This won't need a change in ubiquity after all, we ship a hook script in gnome-keyring to take care of the step of fixing permissions at the end of the install (see gnome-keyring changelog entry about target-config script above). Marking the ubiquity task Invalid.