Bug 79685 - kmail does not honour umask on saving attachments
Summary: kmail does not honour umask on saving attachments
Status: RESOLVED FIXED
Alias: None
Product: kmail
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
: 83362 86325 90080 127547 135104 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-04-15 11:55 UTC by Leo Savernik
Modified: 2008-06-26 14:03 UTC (History)
10 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Patch for setting file permissions of saved attachments (5.47 KB, patch)
2006-07-28 05:26 UTC, Franklin Weng
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Leo Savernik 2004-04-15 11:55:57 UTC
Version:            (using KDE KDE 3.2.2)
Installed from:    Compiled From Sources

When saving an attachment, kmail will store it with permissions 600. This is annoying if I want to access the file from another account.

KMail should respect the umask instead.
Comment 1 David Tseng 2004-06-04 02:07:17 UTC
I agree - came across this annoyance today on new fedora core 2 install. save image attachment to hard disk, scp to webserver. Image is not viewable because of 600 permission.
Comment 2 Michael Nottebrock 2004-09-25 21:47:21 UTC
Hit this bug just now. Still present in KDE 3.3.0 and annoying as hell...
Comment 3 groot 2005-03-01 11:42:27 UTC
until _everyone_ understands umasks and has a sensible one set, privacy problems are more important than user convenience (in the off-chance the user wants to save attachments group-readable, for instance). you may want to remove the fchmod( file.handle(), S_IRUSR | S_IWUSR ) line from kmcommands.cpp (line 2375 in my copy); that will at least show you what mode QFile uses by default.
Comment 4 Michael Nottebrock 2005-03-01 16:35:36 UTC
You mean, until everyone, including all operating system vendors out there agrees with your idea of a sensible umask (my guess: 066 - which isn't really sensible at all, but that's not the issue anyway), i.e. WONTFIX. This just isn't acceptable, sorry.

Kmail's current behaviour is just wrong. It is the same degree of wrong (and stupid) as Outlook's idea of providing protection from malicious attachments by using a hardcoded list of bad file extensions to irrevocably strip the attachments from the mails upon reception.

If you must insist on protecting the user from basic unix functionality, fine, but please, PLEASE, make the filemode of attachments configurable *somewhere*, even if that means hiding it in a six level configuration dialog and three consecutive warnings when trying to change the default.
Comment 5 Rishi Gangoly 2005-09-29 15:45:59 UTC
Hi... I've installed libpam-umask package and configured /etc/pam.d/kdm with umask 002. 

This has taken care of this problem for konqueror but not for kmail. 

The version of kmail I'm using is 1.7.1 (KDE 3.3.2)

It would be great if this problem can be fixed in Kmail too. Thanks and regards
Comment 6 russell 2006-02-03 17:41:16 UTC
Another vote here for removing the enforced 0600 on saving attachments.

Our users often want to save an attachement to a common shared area but that's not a lot of use as other users can't then open the flipping things! :-(

Purleeze, make it a kmail configurable option even if the default is a draconian 0600.
Comment 7 Juha Tuomala 2006-02-05 08:51:31 UTC
> save image attachment to hard disk, scp to webserver. 
> Image is not viewable because of 600 permission. 

I've been wondering exactly the same. Please fix this.
Comment 8 Ismail Onur Filiz 2006-04-16 22:27:39 UTC
*** Bug 83362 has been marked as a duplicate of this bug. ***
Comment 9 Ismail Onur Filiz 2006-05-18 08:30:20 UTC
*** Bug 127547 has been marked as a duplicate of this bug. ***
Comment 10 Franklin Weng 2006-06-13 17:02:59 UTC
Two years passed, and the status is still NEW... *sob*
Comment 11 Franklin Weng 2006-07-28 05:26:17 UTC
Created attachment 17146 [details]
Patch for setting file permissions of saved attachments

Hi,

I studied Qt and the tried to fix this problem.

Not very good, but worked. Just for your information. Maybe somebody
could give it a better interface. ;-)
Comment 12 Franklin Weng 2006-07-28 05:28:40 UTC
Oh, I forgot one thing. This patch was created using branches/KDE/3.5/kdepim/kmail.
But I have tried that it could be applied to trunk/KDE/kdepim/kmail as well.
Hope this helped.
Comment 13 Konstantin Pelepelin 2006-11-13 08:16:26 UTC
> until _everyone_ understands umasks and has a sensible one set

Strange motivation. Most programs rely on umask, most email clients rely on umask and doesn't consider this harmful, but kmail does. Why?

Please, re-think.

kmail 1.9.4
Comment 14 Boyd Stephen Smith Jr. 2006-11-13 15:25:39 UTC
I agree with comment #13 but think that there is a reasonable compromise: provide some option to honor the umask.  How visible you make this option is a non-issue to me, be it a checkbox in the UI, or some cryptic option in a configuration file.
Comment 15 Jonathan Marten 2006-11-22 21:59:12 UTC
*** Bug 135104 has been marked as a duplicate of this bug. ***
Comment 16 Andres Mujica - SEAQ 2007-01-25 00:53:59 UTC
Hi we can confirm this, we also reported it at (k)ubuntu 

https://bugs.launchpad.net/kdepim/+bug/81381

This is specially needed in multiusers enviroments, as ltsp servers.

Thanks a lot
Comment 17 Thomas McGuire 2007-02-13 11:31:56 UTC
*** Bug 90080 has been marked as a duplicate of this bug. ***
Comment 18 Thomas Riewe 2007-03-01 14:31:51 UTC
Hello out there,

wouldst thou please change the severity of this annoying bug ?

Still existing in KMail 1.9.5 and right now this is the reason
to change to some other Mail-Client if we can't solve it,
because we are using LTSP with 5 users and need to share 
attachements.

Regards,
Thomas
Comment 19 Martin Koller 2007-03-04 22:24:30 UTC
SVN commit 639336 by mkoller:

BUG: 79685

By default, honor umask of the user when saving attachments,
but offer a config entry (without user interface) for those
who explicitely don't like that
([General] section, disregardUmask boolean)


 M  +4 -0      kmail.kcfg  
 M  +5 -1      kmcommands.cpp  


--- branches/KDE/3.5/kdepim/kmail/kmail.kcfg #639335:639336
@@ -87,6 +87,10 @@
     </group>
 
     <group name="General">
+      <entry name="disregardUmask" type="Bool">
+        <label>Disregard the users umask setting and use "read-write for the user only" instead</label>
+        <default>false</default>
+      </entry>
       <entry name="SystemTrayEnabled" type="Bool">
         <label>Enable system tray icon</label>
         <default>false</default>
--- branches/KDE/3.5/kdepim/kmail/kmcommands.cpp #639335:639336
@@ -2627,7 +2627,11 @@
           i18n( "KMail Error" ) );
       return Failed;
     }
-    fchmod( file.handle(), S_IRUSR | S_IWUSR );
+
+    // #79685 by default use the umask the user defined, but let it be configurable
+    if ( GlobalSettings::self()->disregardUmask() )
+      fchmod( file.handle(), S_IRUSR | S_IWUSR );
+
     ds.setDevice( &file );
   } else
   {
Comment 20 Leo Savernik 2007-03-05 20:00:30 UTC
Am Sonntag, 4. März 2007 schrieb Martin Koller:
>      RESOLVED FIXED



THANK YOU! You solved one of the most annoying kmail bugs. Regarding earlier 
comments, I was already afraid it'd be confined to stay indefinitely.
Comment 21 Xavier Gillet 2007-03-06 10:43:05 UTC
Thanks for the correction, but i have still a newbie question ...
I'm not able to correct the sources whith the code above and put it on all the computers of my network without breaking the packets dependancy of my distribution (kubuntu). Then i have to wait the binary version without the bug.
What is the right version number of kmail now ?
Comment 22 Jonathan Marten 2008-05-15 18:44:23 UTC
*** Bug 86325 has been marked as a duplicate of this bug. ***
Comment 23 davidblunkett 2008-06-11 11:14:06 UTC
I am using kamil 1.9.6 from suse and I am completely baffled by this- 

I have no option to set anything to do with perms and kmail does not honour my umask, am I missing something?
Comment 24 Allen Winter 2008-06-12 17:45:17 UTC
You need to set this configuration option by hand in your kmailrc file.
This info was never added to the KMail handbook, which is my fault.

Quit from KMail or Kontact, which ever one you use.

Start up your favorite editor and open the file .kde/share/config/kmailrc
from your home folder.

Scroll down to the heading [General] and add the line:
disregardUmask=true

Comment 25 Ferdinand Gassauer 2008-06-12 18:37:34 UTC
can this be eventually be changed to 
respectUmask=true/false
to avoid double negation?

Comment 26 davidblunkett 2008-06-18 12:02:50 UTC
I think I am still missing something: I tried this (comment 24) and tried disregardUmask=false but I still get read only attachments and read only docs on opening from kmail, my umask is 22 but somewhere along the line kmail is not respecting this.

The comments in the code indicate that true = "disregard users umask and use u=rw instead", so if it is false I should get my umask (022) and if it is true I should get still be able to r/w.  Any idea what is not going right for me?

I can see kmail reading and rewriting this option (because it sorts it on saving). I don't know where kmail picks up my umask or how I can check what value it thinks it has (I cannot build these packages at the moment because of a missing dependency but I think this is an unrelated distro problem).

Any suggestions? Thanks!
Comment 27 Paul Worrall 2008-06-18 18:49:33 UTC
When you say in comment 24 "...on opening from kmail,...", are you talking about opening attachments directly from within received emails?  In this case, documents are opened read-only (at least OpenOffice ones are). This bug however is about the file permissions you get when you save the attachment to a stand-alone file (e.g. by right-click --> Save As...).  Sorry if I've misunderstood comment 24.
Comment 28 davidblunkett 2008-06-19 10:00:28 UTC
RO when I open a document or drag a document to the Desktop, I haven't tried saveas...

It appears that my concern is with a different but (outlined below)

My main concern is opening a document directly - a long time back opened documents were R/W (umask in fact) but some newbies lost edits because they did not realise they were opened in /tmp and kmail cleaned them before quitting.  The developers then enforced RO opening.  In my opinion this was wrong - the correct action would be to: get kmail to check for changes and only clean if no changes had been made to files in /tmp but to optionally issue a warning otherwise AND for the RO to be optional and by default selected.  In this case no one who didn't know what was going on would have a problem and the rest of us could have RW / umask if we wanted.


For several years I just built my own kmail with a hack to remove the RO enforcement but ran into trouble building lately and filed a bug which got marked as the same as this one.

What I am after is an option to set the perms of documents you open directly from kmail and a bit of smart handling of changes to tmp files. I only personally care about the former.  My problem is I get sent loads of word docs, the formatting breaks in translation to OO and OO won't let you change RO documents so you have to go through a save:as process (currently broken in the current SUSE OO) or drag the file to the Desktop, change its perms and then open it. All just to fix the borken font so you can read it and discard it.  This happens to me 1/2 dozen times a day and is really annoying.  Yes, I agree OO should be wiser, yes I agree my colleagues should be more enlightened etc but no of this can change and it does not seem unreasonable that kmail allows the user to set the permissions of the files it opens.
Comment 29 Jonathan Marten 2008-06-26 14:03:58 UTC
Regarding comment #28 3rd paragraph:  OpenOffice here (version 2.3.1) seems to handle read-only files reasonably sensibly.  Opening the file:

   -r-------- 1 jjm users 25K Nov 19  2007 biscuits1.ods

(which is the permission as an attachment saved from KMail) opens it in OO in read-only mode.   Clicking the "Edit File" button displays the message

   This document cannot be edited, possibly due to missing access rights.
   Do you want to edit a copy?

Clicking "Yes" then reopens the document as a read-write "Untitled".  So no need to save, change permissions, reopen, etc in order to print or make any changes.  If you need to save the edited copy then "Save as" will do that - and it's a good thing to enforce explicit saving rather than just writing the file back to /tmp, where all the contents of that will be lost on a reboot.