Description: If I change a file owned by another person, and save it, 1. the file will change ownership to me, 2. the file will loose all added individual permissions. It will only keep the inherited permissions from the above folder(s). This is not the expected usual windows behaviour and can have serious side effects in professional use. E.g. if you get a inherited creator/owner permission, you suddenly have full rights for the file when you before had only the right to change the contents of the file. You can change permissions by yourself when you should not. Tried with writer and calc, LibreOffice still version 6.1.6.3. Tried afterwards with LibreOffice 6.2.4, seemingly additional permissions are kept now, but the owner changes still, the owner will get full rights if inherited creator/owner permissions are present from the above folder, the previous owner could probably get less, inherited permissions. Before version 6 I had 5.2.5.1. So I reverted to 6.0.7.3, everything is okay with it. Perhaps the problem is somehow related to bug 125401. Please fix it as soon as possible, especially in the still version. Steps to Reproduce: 1. Create a file with inherited and manually permissions 2. Change the owner to someone else. 3. Edit the file and save it. 4. You will become owner and the file will keep only the inherited permissions. Actual Results: Original owner and permissions are overwritten. Expected Results: Owner and permissions should be kept. Reproducible: Always User Profile Reset: No Additional Info:
Indeed, it's related to the same change that caused tdf#. And that it's fixed incompletely in 6.2 is likely to > Security resource attributes (ATTRIBUTE_SECURITY_INFORMATION) for the original file are not preserved until Windows 8 and Windows Server 2012 mentioned in https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-replacefilea. So possibly the OS information missing in the report is Windows 7? Seems that we need to disable the fastpath for Win7 case.
Forgot to set NEEDINFO needed for further steps: please mention the affected OS, and put back to UNCONFIRMED. Thanks.
Also strange that it's problematic with 6.1.6 - that version should behave identically to 6.2, because the fix was backported to 6.1.3...
The OS versions are Windows 10 Pro 64 bit, 1809 and 1803, but also Windows 7. Why 6.2 behaved differently, I am not sure anymore. Perhaps I tested with a different file with other inherited and added permissions.
Confirming wrt owner change (in 6.2 and current master). There's no use to check 6.1, since no new builds will be released there anyway. I can't check at the moment how the behavior differs in case of Windows 7. I am not sure what to do here. The new behavior is consistent with major Windows applications, like MS Word, or Autodesk AutoCAD. So I'm inclined to close this as WONTFIX, given that permissions are kept correctly now. I'm not closing this right now, to have some time to think this over.
*** Bug 126260 has been marked as a duplicate of this bug. ***
Dear Cat65, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
As mentioned in comment 5, this is consistent with other software on Windows. I don't think we have some better way of dealing with the OS security model. Closing WONTFIX. Please reopen if you have a good idea how to deal with this, taking into account that new data is not written directly into the older file, but new file is created side-by-side with the old file, filled with the new data to avoid damage on write failure, and then after the write is finished, the old file is deleted or renamed to backup, and the new one is renamed to the old name.