Bug 82035 - Wrong umask used when creaing directories
Summary: Wrong umask used when creaing directories
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: up2date
Version: 7.3
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Adrian Likins
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2003-01-16 17:10 UTC by Clifford Neuman
Modified: 2007-04-18 16:50 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-04-05 21:17:22 UTC

Attachments (Terms of Use)

Description Clifford Neuman 2003-01-16 17:10:47 UTC
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:

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.

Comment 1 Adrian Likins 2003-01-17 22:49:45 UTC
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.

Comment 2 Clifford Neuman 2003-01-17 23:19:30 UTC
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.

Clifford Neuman

Comment 3 Adrian Likins 2003-08-06 23:01:02 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.