Bug 82035 - Wrong umask used when creaing directories
Wrong umask used when creaing directories
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: up2date (Show other bugs)
7.3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Adrian Likins
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-01-16 12:10 EST by Clifford Neuman
Modified: 2007-04-18 12:50 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-04-05 17:17:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Clifford Neuman 2003-01-16 12:10:47 EST
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.
Comment 1 Adrian Likins 2003-01-17 17:49:45 EST
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 18:19:30 EST
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
Comment 3 Adrian Likins 2003-08-06 19:01:02 EDT
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.