If /tmp is a separate partition, then the tar extract of stageX does not change the mode of the root directory of /tmp, and it ends up root.root 755. Perhaps something somewhere should twat-check the permissions on /tmp at install-time?
try umask=value Set the umask (the bitmask of the permissions that are not present). The default is the umask of the current process. The value is given in octal.
If you install, and create /tmp as a separate partition, the root inode of the partition can to be given mode 1777 using chmod. This is normal and should be done. The response given is not a fix and is not appropriate to this bug.
Not only that, but you do not say where that 'umask' flag is to be set. That isn't an extract from the fstab or mount manpages, and indeed, the ext2 filesystem does not support a umask flag. The bug really is that the root inode of the /tmp filesystem needs its permissions set to avoid silent breakage. Please reopen this bug.
bad martin ;)
Docs team, let's add a well-integrated part to the doc about this issue and others like them (where /foo is a partition)
Should the "chmod 1777 /tmp" be done before or after /tmp is mounted?
I think after is more secure
I'm not exactly sure what the proposed instructions should contain. Are we discussing how to mount different directories on seperate partitions with appropriate permissions via fstab? If so, that kind of depends on which filesystem the user selects, like the ext2 and umask issue listed here. So if someone could clarify exactly what needs to be documented, I'll work up a patch for the install guide.
Not only should it be done after mounting, it _MUST_ be done after mounting, otherwise you change the mode of the mount point inode, not the root inode on the new fs. Can this type of thing not be done as a post-install gimmick on baselayout, rather than requiring user intervention? Most directories are fine root.root, 755. The only things that need checking are things like /tmp and /var/tmp, and .... no others come to mind that are likely to be mount points.
Antifa: I'm already on to it (otherwise I wouldn't have taken the bug myself :)
Created attachment 15880 [details, diff] Proposed patch to installation guide Does this look ok?
No, you mean /mnt/gentoo/tmp and /mnt/gentoo/var/tmp, and why can't this be done by baselayout preinstall/postinstall anyway?
Created attachment 15895 [details, diff] Updated patch Good question (regarding baselayout).
Cc'ing azarah as he seems to be one of the devs in charge of baselayout...
I too have observed this problem However, I see this as a bung in tar. Placing placing comments in install docs, or adding code to some of the install ebuilds is a fix. But isn't this avoiding the root failure/bug being tar? /doug
*** Bug 22929 has been marked as a duplicate of this bug. ***
I've poseted the following to bug-tar@gnu.org... I'm observing an odd behavior where gnu tar (on Linux) does not restore the permissions on a directory if that directory has a filesystem mounted on it. However, if the same directory exists without a FS mounted on it, tar correctly sets the permissions. Is this the expected behavior of gnu tar? Brief Details... # cd /root/test_dir # tar -x -p -v -v -f test-tar.tar drwx------ root/root 0 2003-10-17 03:43:17 ./ drwxr-xr-t root/root 0 2003-10-17 03:43:17 ./fail/ drwxr-xr-t root/root 0 2003-10-17 03:43:17 ./pass/ # ls -la total 3 drwx------ 4 root root 96 Oct 17 03:44 . drwx------ 22 root root 1176 Oct 17 03:44 .. drwx------ 2 root root 40 Oct 17 03:44 fail drwxr-xr-t 2 root root 48 Oct 17 03:44 pass # df /root/test_dir tmpfs 1031608 0 1031608 0% /root/test-tar/fail This happens with reiser, tmpfs, ext2 as well as with different chmod bits on the 'fail' directory in the archive. I can post the script I used to produce these results. Thanks in advance, Doug
I wonder when the next version of TAR will come out.... Paul Eggert <eggert@CS.UCLA.EDU> writes: Come to think of it, it's probably because tar doesn't update the metadata on a directory unless it created it. With other directories, it can rmdir the directory and then mkdir it; but it can't do that with mount points. The behavior in this area will change in the next tar version; at that point the problem may be moot.
I just had this happen with a newly installed gentoo and the only problem I saw ralated to the /tmp permission was that only root can login to Gnome. So at least for now something can be put in the docs at the same place as the note about adding a regular user... BUT SOMETHING NEED TO GO INTO THE DOCS NOW!!! I saw more people in the forum struggling with the same problem. The thing is that there is not much of an error log from the faulty X/Gnome login. .xsession-errors: /etc/X11/gdm/PreSession//Default: Registering your session with wtmp and utmp /etc/X11/gdm/PreSession//Default: running: sessreg -a -w /var/log/wtmp -u /var/run/utmp -x "/var/lib/gdm/:20.Xservers" -h "" -l :20 joel /joel
Martin, I'm going to add a note to the documentation and leave you with the decision on wether or not to close the bug.
*** Bug 34953 has been marked as a duplicate of this bug. ***
everything should be covered
