Hide Forgot
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): How reproducible: Didn't try 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 Additional info:
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 #!/bin/sh umask 002 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 I did. 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 desktop.
*** 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 useability issue.
umask as a mechanism "works" iff applications like rpm do not change the value. Consider how much security one gains with umask 0777 (which would prevent any non-root access => totally secure) if all applications routinely reset the umask. 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. UPSTREAM
*** 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 umask 002 else umask 022 fi
(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 forbid) BSD... 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 post-install hook?
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 pnasrat@redhat.com's account has been closed
Reassigning to owner after bugzilla made a mess, sorry about the noise...
rpm 4.4.2.3-0.1.rc1 in rawhide sets umask to 0002 always so this should be fixed (finally)
*** Bug 453749 has been marked as a duplicate of this bug. ***