FS#7461 - pacman 3.0.5 doesn't install xorg-server with correct (suid) permissions

Attached to Project: Pacman
Opened by Jonathan Frazier (wide-eye) - Tuesday, 19 June 2007, 00:49 GMT
Last edited by Dan McGee (toofishes) - Wednesday, 20 June 2007, 21:53 GMT
Task Type Bug Report
Category General
Status Closed
Assigned To Jan de Groot (JGC)
Aaron Griffin (phrakture)
Dan McGee (toofishes)
Architecture All
Severity Critical
Priority Normal
Reported Version 3.0.5
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Summary and Info:
pacman doesn't install x with correct suid permissions.

xorg-server 1.2.0-5 permissions with pacman 3.0.5:
-rwxrwxrwxrwx 1 root root 1615268 2007-04-08 0:55 /usr/bin/Xorg

xorg-server 1.2.0-5 permissions installed with pacman 3.0.4
-rws-r-x-r-x 1 root root 1615268 2007-04-08 05:55 /usr/bin/Xorg

Steps to Reproduce:
pacman -Syu
pacman -U pacman-3.0.5-1.pkg.tar.gz (it isn't on my mirror yet)
pacman -S xorg-server
startx (as user gives permission denied errors, stays in console)

workaround:
rebuilding xorg-server with new makepkg fixes this bug.

possibly related:
I have also seen a similar bug with the community/fcron package installing with any version of pacman 3. It installs fine with pacman2.x or rebuilding fcron package using pacman 3 installs fine. [1]

[1] http://aur.archlinux.org/packages.php?do_Details=1&ID=9215&O=0&L=0&C=0&K=fcron&SB=n&SO=a&PP=25&do_MyPackages=0&do_Orphans=0&SeB=nd

I also file this bug as http://bugs.archlinux.org/task/7458 but it is miscatagorized.
This task depends upon

Closed by  Dan McGee (toofishes)
Wednesday, 20 June 2007, 21:53 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed in 3.0.5-2, fix checked into pacman CVS for next release (which should be soon since this is big), and fix checked into GIT.
Comment by Jonathan Frazier (wide-eye) - Tuesday, 19 June 2007, 05:51 GMT
the file that is broken in fcron is /usr/bin/fcrontab, which is set suid.

---s--s--x 1 cron cron 47560 2007-06-14 19:15 /usr/bin/fcrontab
Comment by Andrew Fyfe (space-m0nkey) - Tuesday, 19 June 2007, 14:37 GMT
Not sure how you fixed this by rebuilding the package, the permissions are correct in xorg-server-1.2.0-5.pkg.tar.gz. The problem is with either libarchive I think and related to the /tmp permission problem that Aaron hacked up a fix for (http://projects.archlinux.org/git/?p=pacman.git;a=commit;h=4e6b7c1cde4c0ac1d035b51f9af19510a7c9135e)
Comment by Dan McGee (toofishes) - Tuesday, 19 June 2007, 15:12 GMT
That hack is in pacman CVS here (Revision 1.132):
http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/lib/libalpm/add.c?cvsroot=Pacman

And as Andrew alluded to, not sure how a package rebuild would change anything unless it was the package itself that was broken in the first place (and it seems not to be).
Comment by Jonathan Frazier (wide-eye) - Tuesday, 19 June 2007, 20:58 GMT
as odd as it may seem, that is what i see.
Comment by Jonathan Frazier (wide-eye) - Wednesday, 20 June 2007, 10:39 GMT
here's the package that I made that installs correctly.
http://24.23.187.112/3.0.5-built-xorg-server-1.3.0.0-1-i686.pkg.tar.gz

I will try and keep the file up for few days.

also, this bug is affecting everyone i see on irc who is upgrading/installing today. is a downgrade until fixed in order?
Comment by Dan McGee (toofishes) - Wednesday, 20 June 2007, 13:35 GMT
I can verify this permissions bug, which is odd, after I install your package. Listing the permissions or manually extracting the files using either tar or bsdtar gives no indication that the two packages would be any different.
Comment by Dan McGee (toofishes) - Wednesday, 20 June 2007, 14:39 GMT
Going along with my comment above- I tried rebuilding the xorg-server package myself and installing it, and the permissions are the same as those in the 'official' xorg-server package. Now I'm really confused.
Comment by Dan McGee (toofishes) - Wednesday, 20 June 2007, 21:33 GMT
Fixed in the newest release of pacman, 3.0.5-2. This bug was a bad one.

Quick rundown of what happened:
The files this happened to seemed to be unrelated, but were not. The common link was just that- a symlink to the file. When this existed, an explicit chmod done by pacman caused the symlink permissions (usually 777) to be applied to the file it was pointing to, causing all sorts of issues.
Comment by Jan de Groot (JGC) - Wednesday, 20 June 2007, 21:43 GMT
Hmm, this reminds me of a bug we had in coreutils a while ago, it also followed symlinks when doing a chmod on a symlink.

Loading...