We have the following Problem in this Case: User 1 created a File on a Server (via Servermode) and edited it. User 2 (logged in via Servermode) opens this File, changes somethings and the File has changed with the identity from User 1. So it happens that there are some Changes, User1 doesn't know about. But the File shows his name. And the Security of this whole Process is unclear, if User 2 is able to work in the Name from User 1. It just happens if you are logged in, in Servermode that User 2 gets the foreign UID/GID. Example: > -rw-rw-r-- 1 User1 User1 101 9. Okt 21:42 > .~lock.beta-testing-fixing-progress.doc# But User1 didn't worked on this file on this day
Here is a Use case to understand the Problem a little bit better: There are two Users. Max (who created the file) and Tom (who wants to change the File) Max was able to change the lo-file into a pdf via servermode: unoconv -c "socket,host=127.0.0.1,port=18888;urp;StarOffice.ComponentContext" file.odt ---- After this Tom wants to overwrite the pdf. So he changed the rights to -rw--w---- 1 nsanli nsanli 49689 Jan 18 15:00 file.odt and was able to overwrite the old pdf with "socket,host=127.0.0.1,port=18888;urp;StarOffice.ComponentContext" /home/Max/file.odt ----- And also after Tom has changed the rights to: -rw------- 1 Max Max 49689 Jan 18 15:00 file.odt -rw------- 1 Max Max 91699 Jan 18 15:06 file.pdf Tom was able to overwrite both files and the files are still owned by Max who hasn't touched them anymore. So it's possible for Tom to make changes in the name from Max. Without max knowing that he made this changes.
A colleague told me he cant reproduce my problem which i described below, so here is another try to clear it up: Both Users are logged in via Servermode: unoconv -c "socket,host=127.0.0.1,port=18888;urp;StarOffice.ComponentContext" file.odt 1. User 1 creates creates /home/user1/file.odt 2. executes: foo --bar /home/user1/file.odt 3. executes: baz file.pdf Then User2 4. creates /home/user2/file.odt 5. executes: cd /home/whatever/file.odt 6. executes: foo --bar home/user1/file.odt After this the /home/whatever/file.whatever gets overwritten from User2 and the name from User1 stays.
Sorry, the case is just a example-test. Copy-past error. I will add a instruction asap.
Hello Nadi, Thank you for reporting this. May I ask you to make your bug report cleaner so team could work on it. You are stating issues with Libreoffice server mode but the example you are using are using the command "unoconv" which is to my knowledge not a Libreoffice command. It would be useful if you add more details and exact steps to reproduce this issue you are facing. I'm setting the bug status to NEEDINFO, Please set it to UNCONFIRMED again after providing the requested data. You can always visit our QA channel #libreoffice-qa@freenode if you need help with bugs https://irc.documentfoundation.org/?settings=#libreoffice-qa
These are instructions to reproduce the problem here on Debian stretch, package versions are: - libreoffice 1:5.2.7-1+deb9u9 - unoconv 0.7-1.1 1. user1 creates /home/user1/file.odt with text "test" 2. user2 creates /home/user2/file.odt with text "secret", only readable for user2 (chmod 600 file.odt) 3. user2 runs (on the same machine): cd /home/user1 unoconv file.odt -> this fails with a uno.IOException, but keeps a process named "soffice.bin" running, which listens on port 2002 4. user1 runs (on the same machine): cd /home/user2 unoconv file.odt -> this creates a world-readable /home/user2/file.pdf owned by user2. This way user1 can read "secret" in the pdf! @Usama: Yes, unoconv is not part of libreoffice, but until I read your comment we thought it just starts libreoffice in a certain way, so the problem is caused by libreoffice. But now I think it rather is a unoconv issue, despite the process being named "soffice.bin". Should we move this bug report to the unoconv project? (and even if it is not directly a libreoffice problem, can you reproduce it using my instructions? If yes, with which versions of libreoffice and unoconv?)
(In reply to Thomas Arendsen Hein from comment #5) > @Usama: Yes, unoconv is not part of libreoffice, but until I read your > comment we thought it just starts libreoffice in a certain way, so the > problem is caused by libreoffice. But now I think it rather is a unoconv > issue, despite the process being named "soffice.bin". > Should we move this bug report to the unoconv project? > > (and even if it is not directly a libreoffice problem, can you reproduce it > using my instructions? If yes, with which versions of libreoffice and > unoconv?) I think it wouldn't hurt to report it to https://github.com/unoconv/unoconv/issues If the unoconv devs determine the problem is in LibO, then we can continue here.
Hello Nadi, Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
(In reply to Xisco Faulí from comment #7) > Hello Nadi, > Could you please try to reproduce it with the latest version of LibreOffice > from https://www.libreoffice.org/download/libreoffice-fresh/ ? > I have set the bug's status to 'NEEDINFO'. Please change it back to > 'UNCONFIRMED' if the bug is still present in the latest version. Nadi is no longer working on this. I can try to reproduce it with the new version, but this will take some time, so it would be great if someone else could try it with my instructions from comment #5.
Dear Nadi Sanli, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear Nadi Sanli, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp