[buildd-tools-devel] Bug#584961: Bug#584961: schroot: lvm-snapshot device lock permission failure

Roger Leigh rleigh at codelibre.net
Mon Jun 7 21:38:35 UTC 2010


On Mon, Jun 07, 2010 at 01:30:22PM -0700, Zach Carter wrote:
> When a non-root user is accessing an lvm snapshot chroot, the call to lockdev 
> is made with insufficient permissions, resulting in this error:
> 
> E: test-f13-401b1c48-570f-48bb-8389-4b6d44f18577: Failed to lock chroot: 
> /dev/fastvg/f13lv: Failed to lock device: Failed to lock device
> 
> This issue can also be reproduced in schroot 1.4.2
> 
> Additional details are available in Fedora bug 600638 here:
> 
> 	https://bugzilla.redhat.com/show_bug.cgi?id=600636
> 
> The patch proposed there consists of moving the setuid call to an earlier 
> point before the call to lockdev is made.

Hi Zach,

This is not a bug in schroot.  It's a bug in lockdev, specifically a
patch to lockdev added in RedHat/Fedora which breaks setuid programs.
schroot works fine using the vanilla upstream/Debian lockdev without
this patch.

This is the patch:
  http://lists.alioth.debian.org/pipermail/lockdev-devel/2010-February/000013.html
and this is my review with the rationale:
  http://lists.alioth.debian.org/pipermail/lockdev-devel/2010-February/000039.html
and here's a previous finder of this issue in CentOS:
  http://www.nikhef.nl/~dennisvd/schroot.html

To summarise the above: this patch uses access(2) to see if the user
has permission to use the device.  access(2) is racy, but more
importantly uses the real UID, not the effective UID of the calling
process.  Normally this makes no difference, but in a setuid
program such as schroot, this completely breaks things.  The
suggested fix of the setuid call is AFAICT just working around
this problem; schroot itself only has a single setuid call, and
that's when switching to user context prior to invoking a
program or shell on their behalf.  All the locking and other setup
is always done as root with EUID=0.  I'm not sure why this patch was
introduced, but as it stands it's lockdev at fault here, not schroot.


Due to lack of upstream maintenance of lockdev, the Debian and Fedora
lockdev sources have diverged with the accumulation of different
patches over the last few years.  Debian was the upstream for the last
10 years or so since upstream passed away.  Over the last six months,
mainly with the assistance of Ludwig Nussel (though Karel Zak at Red
Hat was also involved initiating this), we have merged all the
outstanding RedHat patches into upstream.  You can find the git repo
and mailing list at alioth.debian.org.  Some bits were not included or
were reworked , and the access(2) checks were one of those.  We haven't
yet made a new upstream release of this unified tree, but I would
hope this is possible soon (the work is basically done, it just
needs review and testing).


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20100607/e77144dc/attachment.pgp>


More information about the Buildd-tools-devel mailing list