Red Hat Bugzilla – Bug 214359
pirut/pup run pre/post/etc. scripts with strange umask
Last modified: 2007-11-30 17:11:48 EST
When running preinstall/postinstall/etc. scripts, pirut and/or pup (and, for
that matter, system-install-package) choose a strange umask, which results in
things like update-desktop-database and update-mime-database (both of which
create system-wide caches that must be readable by all users) to create
system-wide caches unreadable by anyone other than root.
While it could be argued that vital system components like update-mime-database
and update-desktop-database shouldn't explicitly apply the umask to something
that has to be world-readable to function (and, yes, they do it explicitly),
pirut/pup/whatever shouldn't be running package scripts with an overly
This might be a result of userhelper's involvement. It has never happened with
yum, only with GUI package managers invoked from a non-privileged account.
Based on file permissions, it looks like the umask is probably 0007 when pirut
is running package scripts. This is the normal unprivileged user account umask,
so I'm definitely inclined to blame userhelper's involvement.
Do you have a different umask for your user? From a quick look, there's nothing
that explicitly changes the umask in the usermode source
I have a "umask 007" in my ~/.bashrc, and that's been in there since the
contents of /etc/skel was copied into my shiny new ~ on a RH4 system.
I'm afraid there is no practical way to get the umask the system administrator
has decided to use (it might be set up in any of several shell start up scripts,
using arbitrarily complicated shell scripting) without risking exploitation of
these scripts by unprivileged users. The most pressing trouble is that the way
userhelper now works, it might run these scripts as root with HOME still
pointing to the home directory of the unprivileged user - turning the "execute
kbdrate" permission to "run arbitrary code" permission.
If rpm/the packages depend on a specific umask, they have to set it up
themselves instead of relying on the root's environment.
*** This bug has been marked as a duplicate of 120034 ***