Red Hat Bugzilla – Bug 82035
Wrong umask used when creaing directories
Last modified: 2007-04-18 12:50:04 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 Description of problem: When launching up2date from a user (non root login), and subsquently entering the root password to enable the update, I am finding that some components get installed in directories or with file permissions with protection of no access in group and other. I think this is because up2date is retaining the umask of the account from which I launched up2date, EVEN if installation or update of a component requires that the component be world readable. It is possible that this is an RPM problem, but when I manually use RPM, I change my umask. When launchging up2date by clicking on the exclamation point, this is not an option. Version-Release number of selected component (if applicable): How reproducible: Sometimes Steps to Reproduce: Additional info: The result of this bug is that after certain updates, components of the system seem to no longer work, and for most users, they will have no idea why. When this first happened to me, X stopped working and it took a fair amount of hunting to find out that the problem was that some of the font files for the font server were no longer readable.
do you have any examples of packages getting installed with the wrong umask? Might help evaluating this. What packages were you updating when X stoped working? Want to see if this is a up2date issue, or a packaging issue.
This has happened to me twice. Once the affected program was the X server, which would not start because the fonts directory was protected (actually is was the font server that had the problem, making the fonts unavailable when X started, the problem did not arise until the next reboot which was a couple weeks later). In this particular case it wasn't a directory, but one of the font index files that was unreadable. In the second instance, there was some other component, not X related, where a directory had been created, that was non-readable. I do not recall which compoent. I think I also had a problem with one of the files needed for the audio mixer, but I think that problem cleared up when I did a blanket chmod to fix permissions. In any event, I including a list of the the files in /var/spool/up2date, and will be happy to send you the contents of any of those files if you tell me which ones. The X problem occured between December 13 and January 14. Since the 14th, I am logging in as root before running up2date, so that it doesn't inherit my personal umask. 156 -rw-r--r-- 1 root root 152407 Jan 16 13:29 redhat-linux-i386-7.3-obsoletes.20030116093203 464 -rw-r--r-- 1 root root 468770 Jan 16 13:29 redhat-linux-i386-7.3.20030116093203 156 -rw------- 1 root root 152722 Jan 14 09:43 redhat-linux-i386-7.3-obsoletes.20030113103407 464 -rw------- 1 root root 468368 Jan 14 09:43 redhat-linux-i386-7.3.20030113103407 156 -rw------- 1 root root 152722 Dec 13 08:52 redhat-linux-i386-7.3-obsoletes.20021212134432 464 -rw------- 1 root root 468349 Dec 13 08:52 redhat-linux-i386-7.3.20021212134432 156 -rw------- 1 root root 152458 Dec 3 09:51 redhat-linux-i386-7.3-obsoletes.20021202153723 460 -rw------- 1 root root 465624 Dec 3 09:51 redhat-linux-i386-7.3.20021202153723 156 -rw------- 1 root root 153109 Oct 17 15:01 redhat-linux-i386-7.3-obsoletes.20021017052323 172 -rw------- 1 root root 169619 Oct 17 14:59 kernel-2.4.18-17.7.x.i686.hdr 120 -rw------- 1 root root 117847 Oct 17 14:59 kernel-doc-2.4.18-17.7.x.i386.hdr 768 -rw------- 1 root root 778759 Oct 17 14:59 kernel-source-2.4.18-17.7.x.i386.hdr 172 -rw------- 1 root root 169075 Oct 17 14:59 kernel-debug-2.4.18-17.7.x.i686.hdr 460 -rw------- 1 root root 465614 Oct 17 14:58 redhat-linux-i386-7.3.20021017052323 460 -rw------- 1 root root 465547 Sep 11 08:34 redhat-linux-i386-7.3.20020910045944 116 -rw------- 1 root root 113337 Aug 29 11:30 kernel-doc-2.4.18-10.i386.hdr 164 -rw------- 1 root root 163393 Aug 29 11:30 kernel-debug-2.4.18-10.i686.hdr 460 -rw------- 1 root root 465537 Aug 29 11:30 redhat-linux-i386-7.3.20020829104146 I think the update affecting the fonds was the one on December 13, and I just did not notice the problem until my reboot in January. Clifford Neuman
I need a reproduceable case for this, and havent seen any other problems with it. It sounds like it could be filesystem corruption, but its difficult to say. But rpm is pretty strict about not using umask and the like, installing with the perms/owner/group indicated in the rpm instead.