Bug 214359 - pirut/pup run pre/post/etc. scripts with strange umask
pirut/pup run pre/post/etc. scripts with strange umask
Status: CLOSED DUPLICATE of bug 120034
Product: Fedora
Classification: Fedora
Component: usermode (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Miloslav Trmač
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-07 03:29 EST by Nicholas Miell
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-04-10 06:36:40 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 Nicholas Miell 2006-11-07 03:29:06 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
restrictive umask.

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.
Comment 1 Jeremy Katz 2006-11-08 10:07:39 EST
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
Comment 2 Nicholas Miell 2006-11-08 15:35:51 EST
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.
Comment 3 Miloslav Trmač 2007-04-10 06:36:40 EDT
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 ***

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