Different permission denied errors

[Brian May]

Binary package hint: schroot

Hello,

Since I upgraded to Karmic, schroot is giving me permission denied messages:

brian@sys11:~$ schroot -c sid
E: /dev/sys11/schroot-sid: Failed to stat file: Permission denied

brian@sys11:~$ ls -lad /dev/sys11
drwx------ 2 root root 220 2009-11-23 14:42 /dev/sys11

Quite possibly this is the sole problem here, udev getting the permissions wrong on the LVM directory.

I tried to work around this however, I changed schroot to use /dev/mapper/sys11-schroot--sid instead, now I get:

brian@sys11:~$ schroot -c sid
E: sid-36aeb265-7fbb-477f-bdf7-a9c241eab597: Failed to lock chroot: /var/lib/schroot/session/sid-36aeb265-7fbb-477f-bdf7-a9c241eab597: Failed to write session file: Permission denied

or with full debugging:

brian@sys11:~$ schroot --debug=info -c sid
D(2): Getting keyfile group=etch, key=type
D(2): Getting keyfile group=etch, key=active
D(2): Getting keyfile group=etch, key=run-setup-scripts
D(2): Getting keyfile group=etch, key=run-session-scripts
D(2): Getting keyfile group=etch, key=run-exec-scripts
D(2): Getting keyfile group=etch, key=script-config
D(2): Getting keyfile group=etch, key=priority
D(2): Getting keyfile group=etch, key=aliases
D(2): Getting keyfile group=etch, key=environment-filter
D(2): Getting keyfile group=etch, key=description
D(2): Getting keyfile group=etch, key=users
D(2): Getting keyfile group=etch, key=groups
D(2): Getting keyfile group=etch, key=root-users
D(2): Getting keyfile group=etch, key=root-groups
D(2): Getting keyfile group=etch, key=mount-location
D(2): Getting keyfile group=etch, key=mount-device
D(2): Getting keyfile group=etch, key=command-prefix
D(2): Getting keyfile group=etch, key=personality
D(2): Getting keyfile group=etch, key=active
D(2): Getting keyfile group=etch, key=run-setup-scripts
D(2): Getting keyfile group=etch, key=run-session-scripts
D(2): Getting keyfile group=etch, key=run-exec-scripts
D(2): Getting keyfile group=etch, key=script-config
D(2): Getting keyfile group=etch, key=priority
D(2): Getting keyfile group=etch, key=aliases
D(2): Getting keyfile group=etch, key=environment-filter
D(2): Getting keyfile group=etch, key=description
D(2): Getting keyfile group=etch, key=users
D(2): Getting keyfile group=etch, key=groups
D(2): Getting keyfile group=etch, key=root-users
D(2): Getting keyfile group=etch, key=root-groups
D(2): Getting keyfile group=etch, key=mount-location
D(2): Getting keyfile group=etch, key=mount-device
D(2): Getting keyfile group=etch, key=command-prefix
D(2): Getting keyfile group=etch, key=personality
D(2): Getting keyfile group=etch, key=mount-options
D(2): Getting keyfile group=etch, key=location
D(2): Getting keyfile group=etch, key=device
D(2): Getting keyfile group=etch, key=source-users
D(2): Getting keyfile group=etch, key=source-groups
D(2): Getting keyfile group=etch, key=source-root-users
D(2): Getting keyfile group=etch, key=source-root-groups
D(2): Getting keyfile group=etch, key=lvm-snapshot-device
D(2): Getting keyfile group=etch, key=lvm-snapshot-options
D(2): Getting keyfile group=intrepid, key=type
D(2): Getting keyfile group=intrepid, key=active
D(2): Getting keyfile group=intrepid, key=run-setup-scripts
D(2): Getting keyfile group=intrepid, key=run-session-scripts
D(2): Getting keyfile group=intrepid, key=run-exec-scripts
D(2): Getting keyfile group=intrepid, key=script-config
D(2): Getting keyfile group=intrepid, key=priority
D(2): Getting keyfile group=intrepid, key=aliases
D(2): Getting keyfile group=intrepid, key=environment-filter
D(2): Getting keyfile group=intrepid, key=description
D(2): Getting keyfile group=intrepid, key=users
D(2): Getting keyfile group=intrepid, key=groups
D(2): Getting keyfile group=intrepid, key=root-users
D(2): Getting keyfile group=intrepid, key=root-groups
D(2): Getting keyfile group=intrepid, key=mount-location
D(2): Getting keyfile group=intrepid, key=mount-device
D(2): Getting keyfile group=intrepid, key=command-prefix
D(2): Getting keyfile group=intrepid, key=personality
D(2): Getting keyfile group=intrepid, key=active
D(2): Getting keyfile group=intrepid, key=run-setup-scripts
D(2): Getting keyfile group=intrepid, key=run-session-scripts
D(2): Getting keyfile group=intrepid, key=run-exec-scripts
D(2): Getting keyfile group=intrepid, key=script-config
D(2): Getting keyfile group=intrepid, key=priority
D(2): Getting keyfile group=intrepid, key=aliases
D(2): Getting keyfile group=intrepid, key=environment-filter
D(2): Getting keyfile group=intrepid, key=description
D(2): Getting keyfile group=intrepid, key=users
D(2): Getting keyfile group=intrepid, key=groups
D(2): Getting keyfile group=intrepid, key=root-users
D(2): Getting keyfile group=intrepid, key=root-groups
D(2): Getting keyfile group=intrepid, key=mount-location
D(2): Getting keyfile group=intrepid, key=mount-device
D(2): Getting keyfile group=intrepid, key=command-prefix
D(2): Getting keyfile group=intrepid, key=personality
D(2): Getting keyfile group=intrepid, key=mount-options
D(2): Getting keyfile group=intrepid, key=location
D(2): Getting keyfile group=intrepid, key=device
D(2): Getting keyfile group=intrepid, key=source-users
D(2): Getting keyfile group=intrepid, key=source-groups
D(2): Getting keyfile group=intrepid, key=source-root-users
D(2): Getting keyfile group=intrepid, key=source-root-groups
D(2): Getting keyfile group=intrepid, key=lvm-snapshot-device
D(2): Getting keyfile group=intrepid, key=lvm-snapshot-options
D(2): Getting keyfile group=lenny, key=type
D(2): Getting keyfile group=lenny, key=active
D(2): Getting keyfile group=lenny, key=run-setup-scripts
D(2): Getting keyfile group=lenny, key=run-session-scripts
D(2): Getting keyfile group=lenny, key=run-exec-scripts
D(2): Getting keyfile group=lenny, key=script-config
D(2): Getting keyfile group=lenny, key=priority
D(2): Getting keyfile group=lenny, key=aliases
D(2): Getting keyfile group=lenny, key=environment-filter
D(2): Getting keyfile group=lenny, key=description
D(2): Getting keyfile group=lenny, key=users
D(2): Getting keyfile group=lenny, key=groups
D(2): Getting keyfile group=lenny, key=root-users
D(2): Getting keyfile group=lenny, key=root-groups
D(2): Getting keyfile group=lenny, key=mount-location
D(2): Getting keyfile group=lenny, key=mount-device
D(2): Getting keyfile group=lenny, key=command-prefix
D(2): Getting keyfile group=lenny, key=personality
D(2): Getting keyfile group=lenny, key=active
D(2): Getting keyfile group=lenny, key=run-setup-scripts
D(2): Getting keyfile group=lenny, key=run-session-scripts
D(2): Getting keyfile group=lenny, key=run-exec-scripts
D(2): Getting keyfile group=lenny, key=script-config
D(2): Getting keyfile group=lenny, key=priority
D(2): Getting keyfile group=lenny, key=aliases
D(2): Getting keyfile group=lenny, key=environment-filter
D(2): Getting keyfile group=lenny, key=description
D(2): Getting keyfile group=lenny, key=users
D(2): Getting keyfile group=lenny, key=groups
D(2): Getting keyfile group=lenny, key=root-users
D(2): Getting keyfile group=lenny, key=root-groups
D(2): Getting keyfile group=lenny, key=mount-location
D(2): Getting keyfile group=lenny, key=mount-device
D(2): Getting keyfile group=lenny, key=command-prefix
D(2): Getting keyfile group=lenny, key=personality
D(2): Getting keyfile group=lenny, key=mount-options
D(2): Getting keyfile group=lenny, key=location
D(2): Getting keyfile group=lenny, key=device
D(2): Getting keyfile group=lenny, key=source-users
D(2): Getting keyfile group=lenny, key=source-groups
D(2): Getting keyfile group=lenny, key=source-root-users
D(2): Getting keyfile group=lenny, key=source-root-groups
D(2): Getting keyfile group=lenny, key=lvm-snapshot-device
D(2): Getting keyfile group=lenny, key=lvm-snapshot-options
D(2): Getting keyfile group=lenny-old, key=type
D(2): Getting keyfile group=lenny-old, key=active
D(2): Getting keyfile group=lenny-old, key=run-setup-scripts
D(2): Getting keyfile group=lenny-old, key=run-session-scripts
D(2): Getting keyfile group=lenny-old, key=run-exec-scripts
D(2): Getting keyfile group=lenny-old, key=script-config
D(2): Getting keyfile group=lenny-old, key=priority
D(2): Getting keyfile group=lenny-old, key=aliases
D(2): Getting keyfile group=lenny-old, key=environment-filter
D(2): Getting keyfile group=lenny-old, key=description
D(2): Getting keyfile group=lenny-old, key=users
D(2): Getting keyfile group=lenny-old, key=groups
D(2): Getting keyfile group=lenny-old, key=root-users
D(2): Getting keyfile group=lenny-old, key=root-groups
D(2): Getting keyfile group=lenny-old, key=mount-location
D(2): Getting keyfile group=lenny-old, key=mount-device
D(2): Getting keyfile group=lenny-old, key=command-prefix
D(2): Getting keyfile group=lenny-old, key=personality
D(2): Getting keyfile group=lenny-old, key=active
D(2): Getting keyfile group=lenny-old, key=run-setup-scripts
D(2): Getting keyfile group=lenny-old, key=run-session-scripts
D(2): Getting keyfile group=lenny-old, key=run-exec-scripts
D(2): Getting keyfile group=lenny-old, key=script-config
D(2): Getting keyfile group=lenny-old, key=priority
D(2): Getting keyfile group=lenny-old, key=aliases
D(2): Getting keyfile group=lenny-old, key=environment-filter
D(2): Getting keyfile group=lenny-old, key=description
D(2): Getting keyfile group=lenny-old, key=users
D(2): Getting keyfile group=lenny-old, key=groups
D(2): Getting keyfile group=lenny-old, key=root-users
D(2): Getting keyfile group=lenny-old, key=root-groups
D(2): Getting keyfile group=lenny-old, key=mount-location
D(2): Getting keyfile group=lenny-old, key=mount-device
D(2): Getting keyfile group=lenny-old, key=command-prefix
D(2): Getting keyfile group=lenny-old, key=personality
D(2): Getting keyfile group=lenny-old, key=mount-options
D(2): Getting keyfile group=lenny-old, key=location
D(2): Getting keyfile group=lenny-old, key=device
D(2): Getting keyfile group=lenny-old, key=source-users
D(2): Getting keyfile group=lenny-old, key=source-groups
D(2): Getting keyfile group=lenny-old, key=source-root-users
D(2): Getting keyfile group=lenny-old, key=source-root-groups
D(2): Getting keyfile group=lenny-old, key=lvm-snapshot-device
D(2): Getting keyfile group=lenny-old, key=lvm-snapshot-options
D(2): Getting keyfile group=sid, key=type
D(2): Getting keyfile group=sid, key=active
D(2): Getting keyfile group=sid, key=run-setup-scripts
D(2): Getting keyfile group=sid, key=run-session-scripts
D(2): Getting keyfile group=sid, key=run-exec-scripts
D(2): Getting keyfile group=sid, key=script-config
D(2): Getting keyfile group=sid, key=priority
D(2): Getting keyfile group=sid, key=aliases
D(2): Getting keyfile group=sid, key=environment-filter
D(2): Getting keyfile group=sid, key=description
D(2): Getting keyfile group=sid, key=users
D(2): Getting keyfile group=sid, key=groups
D(2): Getting keyfile group=sid, key=root-users
D(2): Getting keyfile group=sid, key=root-groups
D(2): Getting keyfile group=sid, key=mount-location
D(2): Getting keyfile group=sid, key=mount-device
D(2): Getting keyfile group=sid, key=command-prefix
D(2): Getting keyfile group=sid, key=personality
D(2): Getting keyfile group=sid, key=active
D(2): Getting keyfile group=sid, key=run-setup-scripts
D(2): Getting keyfile group=sid, key=run-session-scripts
D(2): Getting keyfile group=sid, key=run-exec-scripts
D(2): Getting keyfile group=sid, key=script-config
D(2): Getting keyfile group=sid, key=priority
D(2): Getting keyfile group=sid, key=aliases
D(2): Getting keyfile group=sid, key=environment-filter
D(2): Getting keyfile group=sid, key=description
D(2): Getting keyfile group=sid, key=users
D(2): Getting keyfile group=sid, key=groups
D(2): Getting keyfile group=sid, key=root-users
D(2): Getting keyfile group=sid, key=root-groups
D(2): Getting keyfile group=sid, key=mount-location
D(2): Getting keyfile group=sid, key=mount-device
D(2): Getting keyfile group=sid, key=command-prefix
D(2): Getting keyfile group=sid, key=personality
D(2): Getting keyfile group=sid, key=mount-options
D(2): Getting keyfile group=sid, key=location
D(2): Getting keyfile group=sid, key=device
D(2): Getting keyfile group=sid, key=source-users
D(2): Getting keyfile group=sid, key=source-groups
D(2): Getting keyfile group=sid, key=source-root-users
D(2): Getting keyfile group=sid, key=source-root-groups
D(2): Getting keyfile group=sid, key=lvm-snapshot-device
D(2): Getting keyfile group=sid, key=lvm-snapshot-options
D(2): Creating schroot session
D(2): auth uid = 10,000, gid = 10,003
D(2): In users: 1
In groups: 0
In root-users: 1
In root-groups: 0
D(2): pam_putenv: set HOME=/home/brian
D(2): pam_putenv: set LOGNAME=brian
D(2): pam_putenv: set PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games
D(2): pam_putenv: set SHELL=/usr/bin/zsh
D(2): pam_putenv: set TERM=rxvt-unicode
D(2): pam_putenv: set USER=brian
D(2): PAM authentication succeeded for user
D(2): Session ID: sid-4b862782-2097-468f-b6a5-6986a85e0a26
D(2): setup_chroot: chroot=sid-4b862782-2097-468f-b6a5-6986a85e0a26, setup_type=0, chroot_status=1, lock_status=1
D(3): Chroot setup scripts, exec scripts or session failed
D(2): setup_chroot: chroot=sid-4b862782-2097-468f-b6a5-6986a85e0a26, setup_type=2, chroot_status=0, lock_status=0
E: sid-4b862782-2097-468f-b6a5-6986a85e0a26: Failed to lock chroot: /var/lib/schroot/session/sid-4b862782-2097-468f-b6a5-6986a85e0a26: Failed to write session file: Permission denied

If I do it as root instead, I get a different error:

brian@sys11:~$ sudo schroot -c sid
  Volume group "mapper" not found
/etc/schroot/setup.d/90passwd: 2: cannot create /var/lib/schroot/mount/sid-7d92b549-39ec-4668-8d04-742e6428eb62/etc/passwd: Directory nonexistent
E: sid-7d92b549-39ec-4668-8d04-742e6428eb62: Chroot setup failed: stage=setup-start

Where 90passwd is a simple script that copies my passwd entry from LDAP, this is failing, presumably because of the
previous error - quite possibly because it didn't like me changing the path to the chroot in step 1.

=== cut ===
#!/bin/sh -e
getent passwd brian >> "${CHROOT_PATH}/etc/passwd"
=== cut ===

I am using schroot 1.2.3-1

Brian May

[Brian May (brian-microcomaustralia)]

On second thoughts, even if I chmod 755 /dev/sys11 schroot still fails badly as non-root:

E: sid-9a6aa3bc-6afc-4eda-9924-ec90cfee2a8a: Failed to lock chroot: /var/lib/schroot/session/sid-9a6aa3bc-6afc-4eda-9924-ec90cfee2a8a: Failed to write session file: Permission denied

root operation works fine if I use the original /dev/sys11/schroot-sid

Brian May

[Roger Leigh (rleigh)]

Hi,

(I'm the upstream author and Debian maintainer.)

> Failed to lock chroot: /var/lib/schroot/session/sid-9a6aa3bc-6afc-4eda-9924-ec90cfee2a8a: Failed to write session file: Permission denied

This is independent from any of your LVM setup, I think, being a filesystem ownership/permissions failure. Note that schroot is setuid root (or else it won't be able to chroot(2)), so root must be able to write to every directory under /var/lib/schroot. It must also be able to lock the files with fcntl(2), so your filesystem must support this (most do unless you use something very exotic).

> drwx------ 2 root root 220 2009-11-23 14:42 /dev/sys11
This looks wrong. I have 0755 perms on mine. However, since all the mounting of the filesystems is done as root, this shouldn't in an of itself cause a failure.

> sudo schroot -c sid
> Volume group "mapper" not found
 > /etc/schroot/setup.d/90passwd: 2: cannot create > /var/lib/schroot/mount/sid-7d92b549-39ec-4668-8d04-742e6428eb62/etc/passwd: Directory nonexistent
> E: sid-7d92b549-39ec-4668-8d04-742e6428eb62: Chroot setup failed: stage=setup-start
This looks like one or more of the parent directories are nonexistent. Does /etc exist in the chroot. Did anything get mounted on /var/lib/schroot/mount/sid-7d92b549-39ec-4668-8d04-742e6428eb62/ ?

> getent passwd brian >> "${CHROOT_PATH}/etc/passwd"
Note that the default 20nssdatabases script sets the passwd database using getent, so this is unnecessary. If you want to restrict it to a subset of users, that's something we could add to the script as a customisable option (patch welcome).

So far, it's looking like it's probably an ownership or permissions problem on /var/lib/schroot and/or its main subdirectories. They should all be 0755 and files should be 0644 in the session dir.

Note that if you run schroot with -v as well as --debug=info, you'll get diagnostics from the setup scripts which you haven't got in your case. Re-testing with -v as well would be useful.

BTW, there was a new release of schroot, 1.4.0 a couple of days back. In Debian unstable, no idea about Ubuntu. Possibly worth trying if you haven't had any success to date.

Regards,
Roger

[Brian May (brian-microcomaustralia)]

Hello,

Thanks for your response. I hope you will see mine...

Yes, the permissions on /dev/sys11 look wrong to me too. It is however what udev, it is default config gives me. The error message changes when I update the permissions, so I think it is significant.

Unfortunately I can see what is mounted and not mounted, it seems to clean up everything on encountering the error.

I don't seem to have the 20nssdatabases script here, so I can't comment on this.

Permission problem. Hmm. Lets see:

# find /var/lib/schroot -ls
21250634 0 drwxr-xr-x 4 root root 32 Jul 14 2008 /var/lib/schroot
26404548 0 drwxr-xr-x 2 root root 6 Jan 28 09:53 /var/lib/schroot/mount
30510723 0 drwxr-xr-x 2 root root 6 Jan 28 09:53 /var/lib/schroot/session

looks good to me.

Ok, will try that -v option now. Oh wait, the results are identical. There is no extra information :-(.

Maybe I should check if there is a newer version of schroot.

Thanks

Brian May

[Brian May (brian-microcomaustralia)]

Hmm. I installed schroot and schroot-common (versions 1.4.0-1) from Debian/unstable, and it looks like I have exactly the same problem.

brian@sys11:~/tmp/abc/heimdal-1.3.1.rc2$ schroot -c sid
E: sid-1639ab61-65e0-45e1-afd3-9d993578ba51: Failed to lock chroot: /var/lib/schroot/session/sid-1639ab61-65e0-45e1-afd3-9d993578ba51: Failed to write session file: Permission denied

Can you please explain this statement: "since all the mounting of the filesystems is done as root". How is it done as root? In my case it looks like nothing is being run as root unless I run the schroot command as root.

Are the permissions on these files correct?

brian@sys11:~$ ls -l /usr/lib/schroot
total 856
-rwxr-xr-x 1 root root 277208 2010-01-17 10:08 schroot-listmounts
-rwxr-xr-x 1 root root 301748 2010-01-17 10:08 schroot-mount
-rwxr-xr-x 1 root root 293556 2010-01-17 10:08 schroot-releaselock

-
Brian May

[Brian May (brian-microcomaustralia)]

brian@sys11:~/tmp/abc/heimdal-1.3.1.rc2$ ls -l /usr/bin/schroot
-rwsr-xr-x 1 root root 1031200 2010-01-17 10:08 /usr/bin/schroot
brian@sys11:~/tmp/abc/heimdal-1.3.1.rc2$ schroot -c sid
E: sid-8a87aa76-6bb2-4d92-b055-dcec95c12052: Failed to lock chroot: /var/lib/schroot/session/sid-8a87aa76-6bb2-4d92-b055-dcec95c12052: Failed to write session file: Permission denied
brian@sys11:~/tmp/abc/heimdal-1.3.1.rc2$ sudo chmod 777 /var/lib/schroot/session
brian@sys11:~/tmp/abc/heimdal-1.3.1.rc2$ schroot -c sid
E: 05lvm: File descriptor 4 left open
E: 05lvm: File descriptor 5 left open
E: 05lvm: File descriptor 9 left open
E: 05lvm: WARNING: Running as a non-root user. Functionality may be unavailable.
E: 05lvm: /dev/mapper/control: open failed: Permission denied
E: 05lvm: Failure to communicate with kernel device-mapper driver.
E: 05lvm: /dev/mapper/control: open failed: Permission denied
E: 05lvm: Failure to communicate with kernel device-mapper driver.
E: 05lvm: Incompatible libdevmapper 1.02.27 (2008-06-25)(compat) and kernel driver
E: sid-5607b79f-7734-4ec2-b346-46a150617ff7: Chroot setup failed: stage=setup-start

schroot might be setuid root, but it is acting very much like it isn't.

[Roger Leigh (rleigh)]

Hmm, I didn't appear to be notified of your replies, so didn't notice them until now.

It's looking very much like schroot is not being run with full effective root permissions, despite being correctly setuid-root as intended. Are you using anything which could override this? For example, mandatory access controls as provided by SELinux or AppArmor. TTBOMK we aren't in the SELinux policy, so this could be a source of privilege restriction. If this is the case, then this needs sorting out with the SELinux people (I haven't got the knowledge to help here, sorry).

Regards,
Roger

[Brian May (brian-microcomaustralia)]

Hello Roger,

I see you are subscribed to this bug, but not sure when. So I can only hope you will see this ;-)

I think I can positively rule out SELinux, don't have that.

AppArmor seemed very suspect to me too. However I tried stopping AppArmor (I think), and it didn't help:

brian@sys11:~$ sudo /etc/init.d/apparmor stop
[sudo] password for brian:
 * Unloading AppArmor profiles [ OK ]
brian@sys11:~$ schroot -c sid
E: sid-72bbeab8-f26c-4bcb-b86f-fda313a70297: Failed to lock chroot: /var/lib/schroot/session/sid-72bbeab8-f26c-4bcb-b86f-fda313a70297: Failed to write session file: Permission denied

I have seen another problem that was definitely apparmor's fault. I stopped apparmor as above and it worked. Maybe I should try removing the package and rebooting just in case?

Brian May

[Brian May (brian-microcomaustralia)]

Hello Again,

I went to the, perhaps extreme, test of recompiling the kernel without AppArmor support.

I get exactly the same problem.

Brian May

[Brian May (brian-microcomaustralia)]

Strace clearly shows schroot drops its privileges:

...
getuid() = 10003
mlock(0x7f146bcb9000, 32768) = 0
geteuid() = 0
setuid(10003) = 0
getuid() = 10003
geteuid() = 10003
setuid(0) = -1 EPERM (Operation not permitted)
...

before attempting to do the stuff that requires root access:

...
stat("/dev/vg/schroot-lenny32", 0x7fff779e8e88) = -1 EACCES (Permission denied)
...

Brian May

[Brian May (brian-microcomaustralia)]

I think the problem might be related to pam_ldap, maybe it drops privileges?

I put my details in /etc/passwd and /etc/shadow and it works fine.

Brian May

[Brian May (brian-microcomaustralia)]

You previous email didn't seem to come out on Launchpad, so I will
just reply here.

On 7 March 2010 06:59, Roger Leigh <email address hidden> wrote:
> This seems rather more likely than something intrinsic to schroot.
> You should be able to confirm this with gdb by breaking on calls
> to setuid and then doing a backtrace.  schroot itself only calls
> setuid() prior to invoking the command in the chroot, and then again to
> check that privs were dropped correctly.  This should tell us which
> library/function called it.

What gdb shows me seems just so weird, I am just going to print the
results here, without trying to make sense of them.

Note I installed the -dbg packages for libgcrypt and libgnutls.

GNU gdb (GDB) 7.0-ubuntu
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/schroot...(no debugging symbols found)...done.
(gdb) set args -c lenny
(gdb) r
Starting program: /usr/bin/schroot -c lenny
[Thread debugging using libthread_db enabled]
E: /dev/vg/schroot-lenny: Failed to stat file: Permission denied

Program exited normally.
(gdb) break setuid
Breakpoint 1 at 0x7f0fb948ae80
(gdb) r
Starting program: /usr/bin/schroot -c lenny
[Thread debugging using libthread_db enabled]

Breakpoint 1, 0x00007fc557984e80 in setuid () from /lib/libc.so.6
(gdb) bt
#0 0x00007fc557984e80 in setuid () from /lib/libc.so.6
#1 0x00007fc553cf3004 in lock_pool (n=<value optimized out>) at secmem.c:296
#2 secmem_init (n=<value optimized out>) at secmem.c:477
#3 0x00007fc553cf31ba in _gcry_secmem_malloc_internal (size=128) at
secmem.c:509
#4 0x00007fc553cf3248 in _gcry_secmem_malloc (size=128) at secmem.c:544
#5 0x00007fc553cee74d in do_malloc (n=10003, flags=32768,
mem=0x7fff1951a9a8) at global.c:730
#6 0x00007fc553cee77c in _gcry_malloc_secure (n=10003) at global.c:769
#7 0x00007fc553d00fd0 in md_open (h=0x7fff1951aa18, algo=1,
secure=<value optimized out>, hmac=<value optimized out>) at md.c:487
#8 0x00007fc553d010fa in _gcry_md_open (h=0x7fff1951ab08, algo=32768,
flags=<value optimized out>) at md.c:530
#9 0x00007fc5543c09af in wrap_gcry_mac_init (algo=<value optimized
out>, ctx=0x2713) at mac-libgcrypt.c:42
#10 0x00007fc5543a6ee7 in _gnutls_hmac_init (dig=0x7fff1951ab00,
algorithm=GNUTLS_MAC_MD5, key=0x2112350, keylen=24) at
gnutls_hash_int.c:277
#11 0x00007fc5543b7b38 in _gnutls_P_hash (algorithm=<value optimized
out>, secret=<value optimized out>, secret_size=<value optimized out>,
seed=<value optimized out>, seed_size=<value optimized out>,
total_bytes=<value optimized out>, ret=0x7fff1951ad60
"\354\255Q\031\377\177") at gnutls_state.c:811
#12 0x00007fc5543b7d8a in _gnutls_PRF (session=<value optimized out>,
secret=<value optimized out>, secret_size=<value optimized out>,
label=<value optimized out>, label_size=<value optimized out>,
   ...

[Roger Leigh (rleigh)]

Just for the record, Brian brought this up on debian-devel back in March in this thread:
  http://lists.debian.org/debian-devel/2010/03/msg00298.html

This is a serious bug in gcrypt/gnutls. These libraries are modifying global process state in a very intrusive and unjustified way, in this case dropping root privs when you do a simple NSS passwd/group database lookup(!) This isn't something that can be fixed in schroot; please could you reassign it to libgcrypt.

I hope that in the future, pam_ldap can use a library other than gcrypt/gnutls given its severe brokenness and upstream cluelessness.

Regards,
Roger