On Wed, Jul 21, 2010 at 03:36:39PM -0500, Mark Nipper wrote: > While trying to run "schroot -p --debug=notice" on a system with > lib(pam|nss)-ldap installed and configured (in both the chroot and main > system), I'm getting: > D(1): Set GID=1,000 > E: Failed to set supplementary groups: Operation not permitted > D(1): pam_close_session OK > > Presumably this has something to do with the fact that I'm using > LDAP since schroot works on other systems I run (but which don't make > use of LDAP). I've copied over my existing /etc/(group | gshadow | > passwd | shadow) files and even tried creating my user and group > accounts (nipsy) inside of the /chroot/etc versions of those files to > see if it would help (it didn't). > > I'm also seeing this in my logs when attempting the above: > --- > ==> auth.log <== > Jul 21 15:35:43 ginaz schroot[22525]: pam_unix(schroot:session): session > opened for user nipsy by nipsy(uid=1000) > Jul 21 15:35:43 ginaz dbus-daemon: [system] Rejected send message, 2 matched > rules; type="method_call", sender=":1.24" (uid=1000 pid=22525 comm="schroot) > interface="org.freedesktop.ConsoleKit.Manager" > member="OpenSessionWithParameters" error name="(unset)" requested_reply=0 > destination="org.freedesktop.ConsoleKit" (uid=0 pid=22205 > comm="/usr/sbin/console-kit-daemon)) > Jul 21 15:35:43 ginaz schroot[22525]: pam_unix(schroot:session): session > closed for user nipsy > --- > > So it appears like the problem might be related to dbus-daemon > rather than schroot itself? But that's just conjecture on my part.
No idea about what dbus/consolekit actually do, but I think that's a red herring--I /think/ consolekit sends a dbus message as a side effect of opening a new PAM session during PAM authorisation, but I don't have a clue what triggers this or what uses this. > Any advice from here? I'm afraid it's not a bug in schroot, so it's not something we can fix. It's actually a bug in pam_ldap, or more specifically in its dependencies (libgnutls/libgcrypt). libgcrypt has a bug whereby it drops root privileges after allocating memory. This is fine if it's running as a normal user (no effect) or as root (it's still root), but it breaks setuid programs such as schroot, since we still need root privs to do our job (we would have dropped them ourselves a few moments later, but we no longer have permission to complete our work since they got dropped too soon). This is a previously-reported bug, see lists.debian.org/debian-devel/2010/03/msg00298.html http://bugs.debian.org/543941 https://bugs.launchpad.net/ubuntu/+source/schroot/+bug/486944 http://bugs.debian.org/566351 Some of these, the latter in particular, have suggestions for working around this defect, but I'm afraid that until the gcrypt developers see sense and fix this defect (which appears unlikely in the short term), this is not something we can fix ourselves. This is an issue for /all/ setuid-root programs, and so it also affects sudo, su and other similar programs in exactly the same way. Basically, all setuid-root programs using the glibc NSS functions to look up users/groups in LDAP will break. Do feel free to bring this issue up with them independently--it's a serious problem which breaks a lot of things, but which they don't see as a problem(!). Some additional convincing might effect some change. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
signature.asc
Description: Digital signature
