Bug 494440 - rpm corrupts umask on init
Summary: rpm corrupts umask on init
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: 14
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Panu Matilainen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-04-06 21:15 UTC by James Antill
Modified: 2011-01-19 13:41 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-01-19 13:41:27 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description James Antill 2009-04-06 21:15:29 UTC
Description of problem:
% cat /tmp/t.py
#! /usr/bin/python -tt

import os
import sys

if len(sys.argv) > 1:
    import rpm

print os.umask(0)
% umask 0
% python /tmp/t.py
0
% python /tmp/t.py x
18

Comment 1 James Antill 2009-04-06 21:18:05 UTC
 I'm pretty sure this is the culprit:

int rpmReadConfigFiles(const char * file, const char * target)
{
    mode_t mode = 0022;
    /* Reset umask to its default umask(2) value. */
    mode = umask(mode);

Comment 2 Panu Matilainen 2009-04-07 06:15:21 UTC
Yup, this has been there since like 4.4.2.2 to fix bug 83006 and a big pile of duplicates. We could of course move the forced umask() till later in the game, like at beginning of rpmtsRun() which is where it matters most.

Comment 3 Tuomo Soini 2009-04-22 08:07:58 UTC
Forced umask is not only problem here. Worst problem is that rpm doesn't restore previous umask corrupting umask. Other bugs with this are that rpmbuild generates files with mode 644 only. It doesn't honor umask.

rpm --resign package.rpm will change file mode to 644 which shouldn't happen. It shouldn't change file mode from previous one.

I think umask problems in bug #83006 are not rpm umask bugs. They are packaging bugs, RPM should not touch umask.

Comment 4 Jeff Johnson 2009-04-23 01:24:07 UTC
rpm (and every other application) should __NEVER__ change umask.

Every application (including rpm) that changes umask internally is working at cross
purposes with whatver the end-user has specified .

Have fun!

Comment 5 David Zambonini 2009-06-26 11:00:17 UTC
This hit as a bug trying to use mach after upgrading EL5.2 to EL5.3, which depends on group-writable repodata. createrepo imports rpm, which means it gets its umask forced.

The ridiculous situation is that we now need to ensure any app using rpm has its umask protected whenever rpm is imported:

# temporary workaround for #494440
umask = os.umask(0)
import rpm
os.umask(umask)

I think there could be no clearer case that rpm's behaviour is just plain _wrong_

Comment 6 Bug Zapper 2009-11-18 11:42:06 UTC
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 7 James Antill 2009-11-18 13:59:17 UTC
Moving this to F12, as I don't think this has been fixed upstream yet.

Comment 8 Bug Zapper 2010-11-04 11:22:21 UTC
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 9 Panu Matilainen 2010-11-18 11:08:15 UTC
Fixed upstream (finally, duh). Not going to get fixed in F12 at this point, moving to F14 for Fedora tracking (also needed for rawhide + F13).

Comment 10 Panu Matilainen 2011-01-19 13:41:27 UTC
Fixed in rawhide as of rpm-4.9.0-0.beta1.1.fc15


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