#578584 dpkg-deb: building a deb fails within a setgid (DEBIAN) dir

Package:
dpkg
Source:
dpkg
Description:
Debian package management system
Submitter:
Andreas Krüger
Date:
2010-04-21 02:03:16 UTC
Severity:
wishlist
#578584#5
Date:
2010-03-13 09:18:00 UTC
From:
To:
To help investigate bug 571457, I wanted to compile an openvz upstream
kernel obtained by

    cd /usr/src
    git clone git://git.openvz.org/pub/linux-2.6.26-openvz openvz-git-kernel

For the actual kernel compile, I configured and then tried the Debian way:

    cd /usr/src/openvz-git-kernel
    make-kpkg --initrd kernel_image

Expected result: A linux-image .deb package gets built.

Result seen: The build fails, with an error message

    dpkg-deb: control directory has bad permissions 2755 (must be >=0755
and <=0775)

My analysis: base-files sets up /usr/src with the g+s permission bit,
that bit infects my entire source directory tree, make-kpkg doesn't like
that.

My take on this: Various Debian packages should fit together, but
base-files and make-kpkg don't, in this respect.

My own suggestion towards how to achieve cooperation: Drop the g+s bit
from /usr/src.

My workaround does exactly that:

    chroot -R g-s .

Final "pea-counting" remarks on the precise package version:

The build actually failed on a Lenny system with base-files version 5lenny5.

I verified that it is the base-files package that sets up the g+s
permission, via

   rm -rf /usr/src
   aptitude reinstall base-files
   ls -l /usr

But I did this verification on a different system (in fact, an openvz
guest of the Lenny system host) which has "testing" installed.

I didn't bother to retry the entire kernel compilation on that "testing"
system.  (I would be willing to do that if people think it's worth the
effort.)

Regards, and thank you for providing fine software,

Andreas

#578584#10
Date:
2010-03-13 10:10:28 UTC
From:
To:
Hello Manoj.

I'd like to hear your opinion on this as kernel-package maintainer.

On one hand, /usr/src has been sgid-src for ages, so make-kpkg should
probably deal with that gracefully.

On the other hand, I don't really see the point in having /usr/src sgid-src
by default.

While we are at it, I wonder how is this different from /usr/local and
the group staff. The only difference I see is that /usr/local is in
policy while /usr/src is not.

Thanks.


Package: base-files
Version: 5.1
Severity: normal

To help investigate bug 571457, I wanted to compile an openvz upstream
kernel obtained by

    cd /usr/src
    git clone git://git.openvz.org/pub/linux-2.6.26-openvz openvz-git-kernel

For the actual kernel compile, I configured and then tried the Debian way:

    cd /usr/src/openvz-git-kernel
    make-kpkg --initrd kernel_image

Expected result: A linux-image .deb package gets built.

Result seen: The build fails, with an error message

    dpkg-deb: control directory has bad permissions 2755 (must be >=0755
and <=0775)

My analysis: base-files sets up /usr/src with the g+s permission bit,
that bit infects my entire source directory tree, make-kpkg doesn't like
that.

My take on this: Various Debian packages should fit together, but
base-files and make-kpkg don't, in this respect.

My own suggestion towards how to achieve cooperation: Drop the g+s bit
from /usr/src.

My workaround does exactly that:

    chroot -R g-s .

Final "pea-counting" remarks on the precise package version:

The build actually failed on a Lenny system with base-files version 5lenny5.

I verified that it is the base-files package that sets up the g+s
permission, via

   rm -rf /usr/src
   aptitude reinstall base-files
   ls -l /usr

But I did this verification on a different system (in fact, an openvz
guest of the Lenny system host) which has "testing" installed.

I didn't bother to retry the entire kernel compilation on that "testing"
system.  (I would be willing to do that if people think it's worth the
effort.)

Regards, and thank you for providing fine software,

Andreas

[...]

#578584#15
Date:
2010-03-13 10:27:43 UTC
From:
To:
Please note that there are alternate ways to verify such thing without
reinstalling base-files. apt-get is handy to retrieve the .deb package:

# apt-get --download-only --reinstall install base-files

Then you can examine the contents for the .deb without reinstalling:

# dpkg -c /var/cache/apt/archives/base-files_5lenny5_amd64.deb |grep src
drwxrwsr-x root/src          0 2010-01-25 04:26 ./usr/src/

You can also try "apt-get source base-files" and see debian/rules and
debian/2775-dirs.


Anyway, I agree that make-kpkg and base-files should work together,
and I agree that dropping the g+s bit is the easiest way.

The reasons for this bit are mostly historical: That is how it was in
base-files 1.3.5 when I was not the maintainer, and we never bothered
to change it.

I've sent this report to the kernel-package maintainer for his opinion,
but I'll probably drop the bit anyway.

Thanks.

#578584#20
Date:
2010-03-13 15:38:07 UTC
From:
To:
        Well, kernel-package has always advised people to build sources
 in directories where they have write permission, and where the dir
 permissions are such that dpkg-deb is not upset.

        This is not make-kpkg (which does not care): this is dpkg-deb,
 and the proper fix would be to make dpkg-deb not care. This will come
 up with trying to build _any_ package in /usr/src.

        Well, while I can see some merit in the argument that src
 directories should be writable by people in the src group (gives some
 level of nuanced protection), I can also see that in practice it adds
 little, and is only a minor inconvenience for the sysadmin to set such a
 directory up locally if needed. Most people probably rarely use this
 feature.

        I would be OK with you deciding that /usr/src is not longer sgid
 src -- or with you deciding that building packages in /usr/src is not
 supported.

        I would suggest not using the /usr hierarchy, which is meant for
 vendor stuff.

        Correction: dpkg-deb does not like that. And it would not like
 it not matter _what_ package one tries to build there.

        Actually, I would say that building packages in the /usr/src
 hierarchy is not a supported use case.

        manoj

#578584#25
Date:
2010-04-04 11:49:52 UTC
From:
To:
We believe that the bug you reported is fixed in the latest version of
base-files, which is due to be installed in the Debian FTP archive:

base-files_5.2.dsc
  to main/b/base-files/base-files_5.2.dsc
base-files_5.2.tar.gz
  to main/b/base-files/base-files_5.2.tar.gz
base-files_5.2_powerpc.deb
  to main/b/base-files/base-files_5.2_powerpc.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 573701@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Santiago Vila <sanvila@debian.org> (supplier of updated base-files package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)
Format: 1.8
Date: Sun, 04 Apr 2010 13:22:04 +0200
Source: base-files
Binary: base-files
Architecture: source powerpc
Version: 5.2
Distribution: unstable
Urgency: low
Maintainer: Santiago Vila <sanvila@debian.org>
Changed-By: Santiago Vila <sanvila@debian.org>
Description:
 base-files - Debian base system miscellaneous files
Closes: 571083 573701
Changes:
 base-files (5.2) unstable; urgency=low
 .
   * Added question in FAQ to document the fact that some configuration
     files in /etc are never updated on upgrades. Closes: #571083.
   * Changed default /usr/src to be root:root and 755. Closes: #573701.
     The old permissions were of little benefit, and the user can still
     change this after installing a new system anyway.
   * Renamed FAQ to README and added a compatibility symlink.
   * Removed obsolete Depends on base-passwd, as version 2.0.3.4 is more
     than 10 years old and we don't support upgrades which skip releases.
   * Dropped preinst completely, as it was there just to support upgrades
     from very old releases (that we don't support anymore).
   * Removed postinst code that supports upgrades from very old releases.
Checksums-Sha1:
 d9caf0dff7f6a186c49e77da337ec344247f4291 962 base-files_5.2.dsc
 7eb99a87a6e86e8ee1fde5d3e741943d89248ee7 69250 base-files_5.2.tar.gz
 b61cd534703a142d65e4080f2325b2cb750e3acf 61716 base-files_5.2_powerpc.deb
Checksums-Sha256:
 ae945deba9732672621a705761396f9cd6ed238cb7245b24c407be00162c3982 962 base-files_5.2.dsc
 e8cad0c53bbf1d7ed04a2b18928d9a7354f2c95eefd3a469afcd70097cd5d62d 69250 base-files_5.2.tar.gz
 7972251861246d55abc31392576e5dd9c0092b1bd4b714ba39a3aedb55b593a8 61716 base-files_5.2_powerpc.deb
Files:
 bf5c163f79a6646a32599908a84dbf94 962 admin required base-files_5.2.dsc
 13676fbc5ad4abb676d01d627aa8cccd 69250 admin required base-files_5.2.tar.gz
 edd5b097681f9d70e35ae3da979789aa 61716 admin required base-files_5.2_powerpc.deb
iQEcBAEBCAAGBQJLuHdvAAoJEEHOfwufG4syViIH/3hSEvDE9v+EIztUyPHXGvId
9By13Ac9XwaKs/s1O5RIY0ut9wmd37ESYcsi9jfVNI6T2IDxSTEnMc+ZGcH7fJnW
2JANQnl5mcxc+Foouc4hltF3/52hGtEIWsCuiTgVMo+U2h5SC8u8dJd5uhjSAd5A
fv4tMSMVZtrEo+7wE8q2phWXlJHjK8OYEQqHpbBFBBErfhOR2WzurB+ug+rrHKbu
MyqgNSaZabibxfruD0hYIpec2nH65UEBiKsfhldrPO268y/42m1Nk0eiee8NPfd1
O388HeBOgBxnBigjfbHhdw5qfpM7WJdXLWqUlZX4BpCNPMFbgYEXDot9pdDdiz8=
=LFX4
-----END PGP SIGNATURE-----