Red Hat Bugzilla – Bug 83006
Red Hat rpm installs sometimes done using root's umask
Last modified: 2008-07-02 07:03:09 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212
Description of problem:
I've run into this bug several times dating back to the 6.x days, and just ran
into it today and decided I should report it so it gets fixed.
I ran into the latest case of this installing the errata kdebase* on a system
that didn't previously have it. After doing so using the command line 'rpm'
command and later rebooting, X wasn't able to start due to an error that it
couldn't find font 'fixed'. Turns out that kdebase* installs a few fonts, and
when rpm ran mkfontdir it ran it with the umask I use for root, 077. Thus the
fonts.dir file in that directory was mode 0600, and since xfs runs as a user, it
couldn't use the fonts in that directory. Making the file 644 and restarting
xfs allowed X to start normally.
What I'd expect to happen is that rpm would insure that a proper umask is used
when any installation scripts run, just as it insures all files are installed
with the proper permissions regardless of root's umask. My problem was by rpm
leaving a file too secure, and the system was in an unusable state. Someone
else who happens to have root's umask as 000 when they run rpm may leave
critical system files world writeable and open to easy attack.
Since setting root's umask to 077 is very common in security conscious
environments, many people would curse their computers a bit less often if this
could be fixed. Or in my case, unfairly cursing KDE thinking at first it had
tried to take over my GNOME setup.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. set root's umask to 077
2. install kdebase* on a system that doesn't have it
3. reboot, and watch X fail to start
rpm honors existing umask, does not change in any way.
The stickler is "proper umask", as that is ill defined.
I suppose a seperately configurable rpm specfic umask could be
implemented, but that's really not a whole lot different than,
say, having root run an rpm wrapper for installs that does
exec rpm $*
It's hardly worth the effort of implementation in rpm when a wrapper
solves the problem do easily imho.
Seems to me that "proper umask" means the umask that you guys at Red Hat are
using when you test your packages (I hope it is 022, and not 002 like in your
example!) It'd be a one line addition to rpm to have it set the umask root
currently defaults to now, I fail to see how that'd break anything. A few dozen
lines if you added a config option to the rpmrc for this. I knew I could
replace the rpm command with a script and have it exec the real binary to fix
this FOR ME, but I reported it figuring I couldn't be the only one who has ever
(or will ever) run into this. I guess the only saving grace is that people
clueful enough to set a secure umask for root are probably clueful enough to
figure out what went wrong when adding a package caused X startup to break like
You really ought to beware if you ever set a more secure umask for root by
default, you'll probably suddenly see a lot of problems and many of the people
finding them will not be knowledgeable enough to fix them.
The umask used by Red Hat is that distributed with root
configuration files. The value is 002.
There's far more to be done in packages and rpm to install correctly
with all possible values for umask, it's not just having rpm set
a "proper umask" independently of root's.
Try the wrapper, 'tain't hard.
*** Bug 195414 has been marked as a duplicate of this bug. ***
Reopening as this could bite the mime-type and icon caches used in the GNOME
*** Bug 247307 has been marked as a duplicate of this bug. ***
It does bite mime-types. I have to reset my umask to a more insecure one
everytime I run a yum update. It seems rediculous to me that a software package,
which is dependant on permissions, would honour the root umask.
Whether it is considered a bug or not it is affecting systems, and is a
umask as a mechanism "works" iff applications like rpm do not change the value.
Consider how much security one gains with
(which would prevent any non-root access => totally secure) if all applications routinely reset
You gain little security by using umask, there are far more effective security mechanisms, like
SE Linux, than umask these days.
umask in rpm5.org is always set to 0002 for rpm execution.
*** Bug 249180 has been marked as a duplicate of this bug. ***
(In reply to comment #10)
> *** Bug 249180 has been marked as a duplicate of this bug. ***
Don't know how this bug ended up here :-)
My problem was with an 'unowned' directory being created with 0750
permissions when pup was being invoked via consolehelper. Users umask
is 0007 and roots umask is 0022 (fedora default). Something odd
going on here. Will fake up some minimal test cases when I get a chance.
(In reply to comment #1)
> It's hardly worth the effort of implementation in rpm when a wrapper
> solves the problem do easily imho.
Would such a script fix yum, pup, and puplet? Do these guys actually run the rpm
executable or do they operate via librpm (and friends) instead?
(In reply to comment #3)
> The umask used by Red Hat is that distributed with root
> configuration files. The value is 002.
A recent vanilla install of Fedora 7 has the root umask set as 0022.
From the /etc/bashrc:
# By default, we want this to get set.
# Even for non-interactive, non-login shells.
if [ $UID -gt 99 ] && [ "`id -gn`" = "`id -un`" ]; then
(In reply to comment #7)
> It seems rediculous to me that a software package,
> which is dependant on permissions, would honour the root umask.
There might be no easy way around that, especially if the package does not
own the files it is creating. Case in point, anything that runs
update-mime-database during post install.
[root@grebo ~]# rpm -qf /usr/share/mime/aliases
file /usr/share/mime/aliases is not owned by any package
This might even occur indirectly via desktop-file-install.
> Whether it is considered a bug or not it is affecting systems, and is a
> useability issue.
Especially if updates break previously working packages. I found the mime-cache
issue quite difficult to track down when it initially presented itself as a
problem with evince. A problem with permissions did not immediately occur to me.
Created attachment 160392 [details]
small test suite for exploring this issue
I created a small test suite to explore this issue in a repeatable fashion.
This test suite contains a collection of mock packages that can be used for
testing installation permissions under different environments. Specifically,
we are looking at the effect of the root and user umasks when rpm, yum, or pup
is run as root via su, sudo, or consolehelper. We are also looking at the
effect on 'unowned' files and directories which may be created via packaging
errors or indirectly via helper-scripts.
Okay, this is what I got from these tests.
No difference between being run via sudo and being run explicitly as root.
(Huge sigh of relief). Note that pup/pirut and sudo have significantly
different PAM setup, though.
Updates always work as expected when run with explicit umask of 0022. (But we
kinda gathered that would be the case).
If root's umask is 0077 then we get all kinds of negative effects when a
package fails to own its directories or does not take care to assert the
permissions of incidental files that may be created during post-install. (This
accords with earlier remarks).
Now for the nasty bit. If the normal user has a umask of 0007 (as I hope most
web developers would), root has the default umask of 0022, and we upgrade via
pup, then all hell breaks loose. We seem to get an umask of 0007 for file
creation and a umask of 0027 for directory creation. Minor packaging errors,
that would not normally cause any problems, can cause applications to fail or
misbehave. On my system this has been seen to effect info, thunderbird,
icon-theme.cache, and mime.cache.
People on muti-user systems, will want a 0007 umask if they need to permit
world access to, say, ~/public_html. I do this by default because I'm used to
doing web development in that kind of environment. If you also happen to
manage updates via pup and consolehelper then your in trouble.
I admit strong root umask has a limited usefulness when most of root's
activities are automated (SELinux is sooo much better at managing that).
However, a restrictive umask can help when a bleary-eyed, stressed-out,
under-the-hammer, sysadmin is logging in as root at 3am trying to fix a
mission-critical system. That's the time when you accidentally create a
sensitive file with weak permissions, and don't become aware of it until, at
best, you wake up the next afternoon. A restrictive umask _can_ save your job
in a situation like that.
Now, I agree that it is not really rpms job to fix this. On the other hand
something should. We don't want to be in the situation where some newbie admin
is trying to 'do-the-right-thing' by setting a restrictive root umask
post-install, but have their system progressively break as updates flow in.
They will probably just 'blame-fedora' and move to Ubuntu or SuSE or (heaven
So, should rpmbuild fail if an unowned directory is not explictily excluded in
some way? Should update-mime-database and friends check the permissions of the
files it creates. Is there some way that rpm can check files created by the
Created attachment 161323 [details]
extension to the previous test suite
Added a test for system-install-packages (firefox default handler for RPMS).
This shows the same effect as pup. This probably rules out PAM as a source of
the problem since system-install-packages and pup have quite different PAM
configurations. Thinking its got something to do with the shared pirut modules.
Added a new test which explicitly owns the directory but does not explicitly
set the permissions -- no difference in behavior.
User firstname.lastname@example.org's account has been closed
Reassigning to owner after bugzilla made a mess, sorry about the noise...
rpm 18.104.22.168-0.1.rc1 in rawhide sets umask to 0002 always so this should be fixed
*** Bug 453749 has been marked as a duplicate of this bug. ***