Bug 119050 - Second Export To PDF Does Not Honor Umask
Summary: Second Export To PDF Does Not Honor Umask
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
7.6.1.2 release
Hardware: All Linux (All)
: medium normal
Assignee: Miklos Vajna
URL:
Whiteboard:
Keywords:
: 119505 119559 (view as bug list)
Depends on:
Blocks: rename-before-copy-regressions
  Show dependency treegraph
 
Reported: 2018-08-01 19:15 UTC by Dave Richards
Modified: 2023-09-20 08:30 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dave Richards 2018-08-01 19:15:38 UTC
This is a regression that happened sometime between 6.0 and 6.1.   When you export to PDF a second time and write over the top of a previous file, the permissions are set to 600 on Linux.   When you initially create the PDF, it's using the correct permissions (in our case 666).

Replication is super easy;

1) Open Writer, and type in a few words

2) Select File > Export As > Export as PDF

3) Create a file called sample.pdf and everything works:

drichard@desktopnxcloud:/home/largo/tmp$ ls -lad sample.pdf
-rw-rw-rw- 1 drichard drichard 7615 Aug  1 15:12 sample.pdf

4) Follow step #3 again and try and write over the same file.  It will ask if you want to replace it, select [ YES ]

The file that is created is now 600:

drichard@desktopnxcloud:/home/largo/tmp$ ls -lad sample.pdf
-rw------- 1 drichard drichard 7615 Aug  1 15:13 sample.pdf

This file cannot be opened by other users, and will be a showstopper for us.  We use this feature all the time and users share these files with one another.
Comment 1 Xisco Faulí 2018-08-01 21:15:15 UTC
Reproduced in

Version: 6.2.0.0.alpha0+
Build ID: ea39c41fdf63191579d25f327db81db14862251c
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded
Comment 3 Dave Richards 2018-08-02 19:06:55 UTC
I found in my testing that this issue is happening even with regular files such as ODT.  If you create a document and save it as document.odt the permissions are right (666).  If you make changes and save the file, the resulting file is now 600.
Comment 4 Xisco Faulí 2018-08-27 08:59:37 UTC
*** Bug 119505 has been marked as a duplicate of this bug. ***
Comment 5 Xisco Faulí 2018-08-28 09:41:43 UTC
*** Bug 119559 has been marked as a duplicate of this bug. ***
Comment 6 deant 2018-08-28 13:06:19 UTC
current workaround is using libreoffice 6.0, because the bug does not exist there.
Comment 7 Commit Notification 2018-08-28 13:28:55 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=38afe2976eea427999c39ee3a73e7938ec8d5f7b

tdf#119050 sfx2 store: don't inherit temp file permissions when overwriting

It will be available in 6.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 8 Commit Notification 2018-08-28 15:11:30 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "libreoffice-6-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ff0b1f3c8063f4d7c171a9ea2db4efbff16eda39&h=libreoffice-6-1

tdf#119050 sfx2 store: don't inherit temp file permissions when overwriting

It will be available in 6.1.2.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 9 Xisco Faulí 2018-08-29 10:12:06 UTC
Verified in

Version: 6.2.0.0.alpha0+
Build ID: 3bd8316718fdfed454c01a9c4ae6af6beb34437d
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: el-GR (ca_ES.UTF-8); Calc: threaded

@Miklos, Thanks for fixing this!!
Comment 10 deant 2018-08-29 10:13:35 UTC
ty all for the fast respond!
Comment 11 Commit Notification 2018-09-04 08:27:51 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "libreoffice-6-1-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=24177b61e7839a7b9726aed08997b44d08e89f10&h=libreoffice-6-1-1

tdf#119050 sfx2 store: don't inherit temp file permissions when overwriting

It will be available in 6.1.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 12 Jürgen Sauer 2023-09-20 08:25:32 UTC
just reproduced here:
jojo@pc7 2023]$ ls -l
insgesamt 168
-rw-rw-r-- 1 jojo firma 99569 20. Sep 10:14 '2023-09-18 Besprechung vom 14 September 2023.odt'
-rw-r--r-- 1 jojo firma 67945 20. Sep 10:15 '2023-09-18 Besprechung vom 14 September 2023.pdf'
[jojo@pc7 2023]$ umask
0002

The PDF File was just written. It has got the wrong user permissions, as you see above. I expected the PDF to have "0664" or "-rw-rw-r--" as file permission.

This is a really nasty bug, effecting standard company enviroments.
Comment 13 Miklos Vajna 2023-09-20 08:30:32 UTC
Please don't reopen a 5 years old bug with a related problem. The above commit has a testcase, that one still passes, so the original problem is not re-introduced. Thanks.

Feel free to open a new, follow-up report at https://bugs.documentfoundation.org/enter_bug.cgi?product=LibreOffice .