You are not logged in.

#1 2006-08-08 00:28:41

Bebo
Member
From: Göteborg, Sweden
Registered: 2006-06-07
Posts: 207

Sticky bit in unsupported AUR packages

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? smile

Cheers

Offline

#2 2006-08-08 11:01:51

T-Dawg
Forum Fellow
From: Charlotte, NC
Registered: 2005-01-29
Posts: 2,736

Re: Sticky bit in unsupported AUR packages

So the install command inherets the sticky bit of the directory because its mode was not explicitly set. Try prefixing the mode to the install line with a 0 for both

  install -D -m0644 $startdir/src/tomcat.conf.d $startdir/pkg/etc/conf.d/tomcat
  install -D -m0755 $startdir/src/tomcat $startdir/pkg/etc/rc.d/tomcat

and see if you get the sticky bits in the built package.

Does this sticky bit problem happen if you use makepkg alone after downloading and extracting the tarfile?

EDIT:
I see it does not. I'll update aurbuild tonight to change the modes on the downloaded directory. Thanks for bringing this up.

Offline

#3 2006-08-08 12:01:44

allucid
Member
Registered: 2006-01-06
Posts: 259

Re: Sticky bit in unsupported AUR packages

Please explain the proper way to fix old AUR packages after you update aurbuild.

Offline

#4 2006-08-08 15:36:01

wain
Member
From: France
Registered: 2005-05-01
Posts: 289
Website

Re: Sticky bit in unsupported AUR packages

Bebo wrote:

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.

Hello
When you use

$ yaourt -S tomcat

yaourt doesn't use srcpac (because srcpac build as root :evil:)
it's like:

$ tar xfvz tomcat.tar.gz
$ cd tomcat
$ makepkg -Sfw .
# pacman -Uf tomcat-5.5.17-1.pkg.tar.gz

Because makepkg use fakeroot, all files in pkg.tar.gz are owned by root/root. I can't reproduce your problem roll

Offline

#5 2006-08-08 19:02:22

Bebo
Member
From: Göteborg, Sweden
Registered: 2006-06-07
Posts: 207

Re: Sticky bit in unsupported AUR packages

Okay, sorry wain, my mistake, I didn't look carefully enough. But I am stupid enough to build AUR packages as root (have to stop doing that smile), and for those packages there are sticky bits set on directories if I use yaourt.

Well, as I said above, this seems not to be an issue when building in a fakeroot environment. Building as root, this happens. And, when I said "careless use of makepkg" above, I meant downloading the package, unpacking, not looking at the directory permissions, building and installing.

Thanks for the install -m tip, Penguin, I should have thought of that myself smile

Offline

#6 2006-08-08 19:27:26

Bebo
Member
From: Göteborg, Sweden
Registered: 2006-06-07
Posts: 207

Re: Sticky bit in unsupported AUR packages

Whops, I meant setgid, not sticky bit. Hehe smile Never mind, it still shouldn't be there.

Offline

#7 2006-08-08 23:14:08

T-Dawg
Forum Fellow
From: Charlotte, NC
Registered: 2005-01-29
Posts: 2,736

Re: Sticky bit in unsupported AUR packages

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.

Offline

Board footer

Powered by FluxBB