Bug 3283 - broken handling of umask
Summary: broken handling of umask
Status: RESOLVED FIXED
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Libraries (show other bugs)
Version: SVN Trunk (Latest Devel Version)
Hardware: Other other
: P3 normal
Target Milestone: 3.0.0
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-04-19 17:37 UTC by Alex Krohn
Modified: 2004-04-19 12:33 UTC (History)
0 users


Attachment Type Modified Status Actions Submitter/CLA Status
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Krohn 2004-04-19 17:37:32 UTC 
There are a number of places umask is used incorectly, or not set back properly.
Here's two places I found:

Index: lib/Mail/SpamAssassin/Locker/Unix.pm
===================================================================
--- lib/Mail/SpamAssassin/Locker/Unix.pm        (revision 10111)
+++ lib/Mail/SpamAssassin/Locker/Unix.pm        (working copy)
@@ -60,7 +60,7 @@
   my $lock_tmp = Mail::SpamAssassin::Util::untaint_file_path
                                        ("$path.lock.$hname.$$");
 
-  my $umask = 077;
+  my $umask = umask 077;
   if (!open(LTMP, ">$lock_tmp")) {
       umask $umask;
       die "lock: $$ cannot create tmp lockfile $lock_tmp for $lock_file: $!\n";

and:

Index: lib/Mail/SpamAssassin/Util.pm
===================================================================
--- lib/Mail/SpamAssassin/Util.pm       (revision 10111)
+++ lib/Mail/SpamAssassin/Util.pm       (working copy)
@@ -677,7 +677,6 @@
   }
 
   my $reportfile;
-  my $umask = 0;
   do {
     # we do not rely on the obscurity of this name for security...
     # we use a average-quality PRG since this is all we need
@@ -700,7 +699,6 @@
     # ...rather, we require O_EXCL|O_CREAT to guarantee us proper
     # ownership of our file; read the open(2) man page.
   } while (! sysopen (TMPFILE, $reportfile, O_RDWR|O_CREAT|O_EXCL, 0600));
-  umask $umask;
 
   return ($reportfile, \*TMPFILE);
 }

Version 2.63 also has several places that set umask to 0, but never set it back
(which results in leaving permissions wide open on an app that uses spamassassin).
Comment 1 Theo Van Dinter 2004-04-19 18:59:48 UTC 
hrm.  what's up with that?  :(
Comment 2 Theo Van Dinter 2004-04-19 19:13:44 UTC 
should be all fixed now.  r10112.
Comment 4 Theo Van Dinter 2004-04-19 20:27:55 UTC 
Subject: Re:  broken handling of umask

On Mon, Apr 19, 2004 at 08:13:22PM -0700, bugzilla-daemon@bugzilla.spamassassin.org wrote:
> you are not resetting the umask back, and will leave the program in a different
> umask.

Well, if you look at the bottom of the function, before the return, you'll see:

  umask $umask;

which resets the umask to the original version.  So what am I missing?
Comment 5 Alex Krohn 2004-04-19 20:33:15 UTC 
Sorry, svn up gave me a strange conflict, it looked like the bottom wasn't there.