Sticky bit in unsupported AUR packages

Question

Hello,
In my ventures to provide a PKGBUILD for an app called gnump3d, I've come across something with the unsupported (only?) build script packages in AUR that can cause some problems.
Here is an (one) example of such a package:
$ wget --quiet aur.archlinux.org/packages/tomcat/tomcat.tar.gz
$ tar tvzf tomcat.tar.gz
drwxr-sr-x nobody/aur 0 2006-06-27 02:50:53 tomcat/
-rw-r--r-- nobody/aur 938 2006-06-27 02:49:10 tomcat/PKGBUILD
-rw-r--r-- nobody/aur 415 2005-06-16 20:11:45 tomcat/tomcat.conf.d
-rwxr-xr-x nobody/aur 706 2005-06-16 20:11:12 tomcat/tomcat
Notice the owner, group and the sticky bit on the directory. These permissions seem to be standard for the AUR build script packages.
Now, if use aurbuild to build this package, I get this content in the package:
drwxr-sr-x root/root 0 2006-08-08 01:48:05 etc/
drwxr-sr-x root/root 0 2006-08-08 01:48:05 etc/rc.d/
-rwxr-xr-x root/root 706 2006-08-08 01:48:05 etc/rc.d/tomcat
drwxr-sr-x root/root 0 2006-08-08 01:48:05 etc/conf.d/
-rw-r--r-- root/root 415 2006-08-08 01:48:05 etc/conf.d/tomcat
<SNIP>
I'm pretty sure that these sticky bits weren't intended. If I build the package with yaourt, which uses srcpac as a backend, things get more troublesome:
drwxr-sr-x root/549 0 2006-08-08 02:03:00 etc/
drwxr-sr-x root/549 0 2006-08-08 02:03:00 etc/rc.d/
-rwxr-xr-x root/549 706 2006-08-08 02:03:00 etc/rc.d/tomcat
drwxr-sr-x root/549 0 2006-08-08 02:03:00 etc/conf.d/
-rw-r--r-- root/549 415 2006-08-08 02:03:00 etc/conf.d/tomcat
<SNIP>
549 ought to be the group id of aur in the AUR repository.
Careless usage of makepkg can also make this happen. Not building as root, but in a fakeroot environment, seems to prevent it from happen.
From what I can see, the erroneous permissions are created when the install command is used in the PKGBUILD script, within the newly unpacked build script package.
This is certainly not meant to bash the authors of aurbuild or yaourt (or tomcat; many PKGBUILDs use install, mine included), I just wanted to raise the issue. Can something be done about this? Don't know where, though. Removing the sticky bit on the directory in the build script package would be one solution. Or maybe makepkg could warn about erroneous permissions. Or... Or something? Is it a bug or a feature?
Cheers

Answer 1

Ok fixed aurbuild. Now it extracts the tarball from AUR into /tmp then copies it into the build dir which inherets the modes and owenership of the parent directory there (being $HOME), I'm pretty sure this is how tar does it.
As pointed out above this setgid issue only occurred during root user builds.
More info:
-v1.5.1 (August 8, 2006)
*Fixed inhereted setgid bit in the built the package resulting from AUR's set mode of the parent directory in the tarball.
The unwanted inhereted bit occured only under the following circumstances:
- user was root.
- a 'install -m' line was excuted in the PKGBUILD without explicitly setting the first pair of octets, ie 644 instead of 0644
- Any other type of 'chmod' command without the first octet set.
If you have built any packages meeting the criteria list above, rebuild and install offending packages now. Run the update command to get the list of all
packages built from AUR. String them together in a space separated line to aurbuild and use the menu to see if any install/chmod lines were used. You can
use (s) from the menu to skip the current package and move on to the next.