Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#9465 - /tmp has wrong permissions on new installations

Attached to Project: Arch Linux
Opened by Pierre Schmitz (Pierre) - Monday, 04 February 2008, 16:17 GMT
Last edited by Pierre Schmitz (Pierre) - Friday, 08 February 2008, 10:59 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Aaron Griffin (phrakture)
Thomas B├Ąchler (brain0)
Architecture All
Severity High
Priority High
Reported Version 2007.08-2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

When installing Arch (from ftp), /tmp has wrong permissions which will result in all sorts of problems.

We had a similar issue some time ago (http://bugs.archlinux.org/task/7194). As a workaround the filesystem package sets the right permission on install. This workaround was removed after the bug was fixed in pacman/libarchive.

This time the problem does not seem to be pacman nor the filesystem package itself but perhaps the installer. Installing filesystem to another root dir using -r extracts the right permissions.

Two things should be done to make our current isos working again:
* add chmod 1777 /tmp to the filesystem's install script again OR add the same to the initscripts (should be done asap)
* Find the source of this bug and fix it :-)
This task depends upon

Closed by  Pierre Schmitz (Pierre)
Friday, 08 February 2008, 10:59 GMT
Reason for closing:  Fixed
Additional comments about closing:  I uploaded filesystem-2007.11-7 to [testing].

The source of the problem should be fixed with next isos.

However: we should keep this workaround to avaoid any future regressions.
Comment by Aaron Griffin (phrakture) - Monday, 04 February 2008, 18:22 GMT
Actually, I think the problem is that pacman itself creates /tmp if it doesn't exist.

The simplest workaround, of course, is to just create /tmp with the right permissions before doing any pacman related things.
Comment by Tobias Powalowski (tpowa) - Monday, 04 February 2008, 18:28 GMT
why not to just readd the fix we had before?
Comment by Gerhard Brauer (GerBra) - Monday, 04 February 2008, 18:49 GMT
In my opinion it's an installer problem. During install, before any package download/install or reboot, a few dirs are created in $target-Root (/mnt/) and so /mnt/tmp with the wrong permissions.
When using core-isos this is corrected with the fix still in "old" filesystem package.
But when using ftp-iso install with current filesystem the permissions of /tmp aren't corrected.
As Tobias says: reusing the old fix should repair also the ftp-iso install.
Comment by Aaron Griffin (phrakture) - Monday, 04 February 2008, 18:54 GMT
@tpowa: because that would take longer - that's the only reason I suggested it. I'm fairly certain the actual issue is with pacman creating /tmp
Comment by Aaron Griffin (phrakture) - Monday, 04 February 2008, 20:23 GMT
Ok, I will readd the workaround to the filesystem package. In order to prevent this from happening again, lets NOT remove this.
Comment by Aaron Griffin (phrakture) - Tuesday, 05 February 2008, 19:22 GMT
@tpowa: Should I bump the filesystem version to 2008.02 when I do this? Are we close to an ISO release?
Comment by Xavier (shining) - Tuesday, 05 February 2008, 19:33 GMT
Aaron, you sent me a private mail about this issue one week ago, I told you the pacman side was fixed now (in 3.1.1).
See  bug 9183  .
So probably there is an issue in the installer as GerBra said.
Comment by Aaron Griffin (phrakture) - Tuesday, 05 February 2008, 19:39 GMT
Aha, I didn't know it was actually fixed. So if that is in 3.1.1 and pacman DOES create things with the right perms and the filesystem package has the right perms then it must be an installer issue.
Comment by Dan McGee (toofishes) - Tuesday, 05 February 2008, 19:50 GMT
Ugh, I *hate* bad workarounds. Definitely fixed in pacman:
http://projects.archlinux.org/git/?p=pacman.git;a=commit;h=801a26805663b0a79bf619a0fec853293806969b

I'd look to the installer for this problem.
Comment by Xavier (shining) - Tuesday, 05 February 2008, 20:08 GMT
As I said, the pacman side fix is only in 3.1.1.
So which iso was used, and which pacman version?
The original bug report isn't very clear about that.

However, gerbra was apparently saying the tmp dir might be created even before any pacman related stuff is done.
But well, I don't know.
Comment by Gerhard Brauer (GerBra) - Tuesday, 05 February 2008, 20:42 GMT
The ISOs are the current ISOs (Archlinux-i686-2007.08-2.ftp.iso). And as said it's only a problem when using the ftp install method (but then also on the core-iso)
The /mnt/tmp is created directly after selecting the packages to install and when **download** starts.
At this moment we have /mnt/tmp with 0755 and a /mnt/var.
See PNG here: http://users.archlinux.de/~gerbra/tmp-prob.png
First ls i when dwonload starts, second when base packages are installed.
When filesystem 2007.11-6 gets **installed** after download it seems not to overwrite the complete structure in /mnt/ (the dir structure in filesystem has the right permissions). /mnt/tmp (also /mnt/var/tmp) stays with the bad permissions, also when rebooting. The fix with explicit chmod for those dir's correrted this problem - and do so when using core-iso for current install.
Comment by Gerhard Brauer (GerBra) - Tuesday, 05 February 2008, 21:25 GMT
One more comment, for clarification:
I mean not that the installer is guilty or has a bug: the installer during it's work could live in peace with
a 0755 /mnt/tmp. But the installer created this dir initially (mkdir with current umask).

The problem then is, that no process during configuration or installation in base/core corrected this.
From package side i would prefer filesystem to do this. Or (against further damage on /tmp permissions from
"bad" packages, user mistake,...) we could check&repair it during Runlevel-Skripts.
Comment by Gerhard Brauer (GerBra) - Tuesday, 05 February 2008, 21:42 GMT
And another idea for handling this (maybe the best solution):
Let the installer as first action (after preparing harddisk and mount these to /mnt) untar/install the filesystem package. Then we have a good working FHS structure in /mnt/. filesystem is always on core-isos, and we could put it also on ftp-isos.
Comment by Xavier (shining) - Tuesday, 05 February 2008, 21:46 GMT
One thing I don't understand : I have been looking at what looks a lot like arch installer :
http://projects.archlinux.org/git/?p=installer.git;a=blob_plain;f=setup;hb=HEAD

And I can't find anything there that is creating $DESTDIR/tmp .
Comment by Tobias Powalowski (tpowa) - Tuesday, 05 February 2008, 22:23 GMT
yes you are totally right the installer doesn't create those directories at all.
it's the bad combination of pacman 3.0 and the new filesystem package which breaks the ftp install.
Comment by Aaron Griffin (phrakture) - Tuesday, 05 February 2008, 22:25 GMT
Oooh, this is an old iso, with pacman 3.0 on it.

Maybe our install iso should upgrade pacman first before doing anything else? That would solve all problems like this for the future.
Comment by Gerhard Brauer (GerBra) - Tuesday, 05 February 2008, 22:42 GMT
Sorry for pointing to the false direction ;-)
I: "But the installer created this dir initially (mkdir with current umask)."
I've never looked at the source, but i was sooo sure...
Comment by Tobias Powalowski (tpowa) - Wednesday, 06 February 2008, 10:21 GMT
I just dislike autoupdates on ISO, the ISOs were tested before release and then should just work.
Autoupdates always can cause trouble.

Loading...