GNOME Bugzilla – Bug 347238
broken and inconsistent file permissions, when saving attachments
Last modified: 2013-09-13 00:49:15 UTC
Got a mail with one attachment, Content-Type: text/plain. Depending on the way the user chooses to save the attachment, the resulting file permissions differ, being totally inconsistend and somewhat broken. Below is a list of the possible ways to save and the respective resulting file permissions. The location to save the attachment is the very same in all cases. * Open the attachment pane in the header (using the small arrow button next to the attachment count in the header), then drag-n-drop the file icon to Nautilus. Resulting permissions: -rw------- * Click the "Save" button next to the attachment count in the header to save all (here one) attachments. Resulting permissions: -rw-r--r-- * Use the attachment drop-down button (where the attachment actually is in the MIME structure), Save As. Resulting permissions: -rw-r--r-- * Drag-n-drop the attachment button itself (the inline-display toggle button where the attachment actually is in the MIME structure) to Nautilus. Resulting permissions: -r--r--r-- This behavior is totally inconsistent -- 4 ways, 3 different results. Note, that the user does not even have write permissions in the last case above.
For reference: $ touch test $ ls -l test -rw-r--r-- 1 guenther users 0 Jul 11 18:50 test
Created attachment 70354 [details] [review] File permissions for saving attachment changed to -rw-r--r--
ushveen the patch needs some more work. It will interfere the place, where the attachments are opened read-only.
Created attachment 71433 [details] [review] Corrected patch.
Created attachment 71436 [details] [review] Sorry,had missed sumthing in the previous patch.
Fixed to HEAD (with slight modifications). Should this go for stable?
changing the signedness by -em_utils_temp_save_part(GtkWidget *parent, CamelMimePart *part) +em_utils_temp_save_part(GtkWidget *parent, CamelMimePart *part, gboolean mode) breaks other places where this is called, namely ./plugins/import-ics-attachments/icsimporter.c: path = em_utils_temp_save_part (NULL, part); ./plugins/import-ics-attachments/icsimporter.c: path = em_utils_temp_save_part (NULL, part); ./plugins/itip-formatter/itip-formatter.c: new_uri = em_utils_temp_save_part (NULL, part); ./plugins/itip-formatter/itip-formatter.c: new_uri = em_utils_temp_save_part (NULL, part); also, DO update the documentation!!!!!!: /** * em_utils_temp_save_part: * @parent: * @part: * where is "@mode" here? folks, you really discourage potential external contributors if you do not take care of stuff like that. at least i would be pretty pissed.
but except of that, it builds fine. no other patches that have broken the build so far. :-)
My fault. Committed the right fix.
(In reply to comment #6) > Fixed to HEAD (with slight modifications). Should this go for stable? No need to at this point, we are past the last 2.6.x release. (Note that Severity has been raised from normal to blocker by Andre. I assume to force getting a corrected patch in. The bug itself isn't that important...)