From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2)
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):
Steps to Reproduce:
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
156 -rw-r--r-- 1 root root 152407 Jan 16 13:29
464 -rw-r--r-- 1 root root 468770 Jan 16 13:29
156 -rw------- 1 root root 152722 Jan 14 09:43
464 -rw------- 1 root root 468368 Jan 14 09:43
156 -rw------- 1 root root 152722 Dec 13 08:52
464 -rw------- 1 root root 468349 Dec 13 08:52
156 -rw------- 1 root root 152458 Dec 3 09:51
460 -rw------- 1 root root 465624 Dec 3 09:51
156 -rw------- 1 root root 153109 Oct 17 15:01
172 -rw------- 1 root root 169619 Oct 17 14:59
120 -rw------- 1 root root 117847 Oct 17 14:59
768 -rw------- 1 root root 778759 Oct 17 14:59
172 -rw------- 1 root root 169075 Oct 17 14:59
460 -rw------- 1 root root 465614 Oct 17 14:58
460 -rw------- 1 root root 465547 Sep 11 08:34
116 -rw------- 1 root root 113337 Aug 29 11:30
164 -rw------- 1 root root 163393 Aug 29 11:30
460 -rw------- 1 root root 465537 Aug 29 11:30
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.
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.