Bug 214359 - pirut/pup run pre/post/etc. scripts with strange umask
Summary: pirut/pup run pre/post/etc. scripts with strange umask
Keywords:
Status: CLOSED DUPLICATE of bug 120034
Alias: None
Product: Fedora
Classification: Fedora
Component: usermode
Version: 6
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Miloslav Trmač
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-11-07 08:29 UTC by Nicholas Miell
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-04-10 10:36:40 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Nicholas Miell 2006-11-07 08:29:06 UTC
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 15:07:39 UTC
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 20:35:51 UTC
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 10:36:40 UTC
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.