Bug 79685

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.

Hit this bug just now. Still present in KDE 3.3.0 and annoying as hell...

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.

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.

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

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.

> 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.

*** Bug 83362 has been marked as a duplicate of this bug. ***

*** Bug 127547 has been marked as a duplicate of this bug. ***

Two years passed, and the status is still NEW... *sob*

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. ;-)

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.

> 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

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.

*** Bug 135104 has been marked as a duplicate of this bug. ***

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

*** Bug 90080 has been marked as a duplicate of this bug. ***

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

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
   {

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.

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 ?

*** Bug 86325 has been marked as a duplicate of this bug. ***

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?

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

can this be eventually be changed to 
respectUmask=true/false
to avoid double negation?

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!

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.

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.

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.