Bug 124853 - LO .desktop files belong to root and not user
Summary: LO .desktop files belong to root and not user
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.2.3.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-04-20 06:04 UTC by alucardnoir
Modified: 2020-05-27 09:35 UTC (History)
3 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 alucardnoir 2019-04-20 06:04:10 UTC
Description:
On Solus Budgie, and verified by someone else on KDE Neon, (https://discuss.getsol.us/d/779-libreoffice-borked) normally created .desktop files for LO belong to root as opposed to the user. This means they can't be trusted by normal users and thus be used as desktop icons. This is not expected behavior and since it's both distro and DE agnostic seems to originate with LO.

Steps to Reproduce:
1.Open a Linux distro with a DE that suports desktop icons.
2.Open the menu or a file explorer
3.Drag the LO icon, or the Writer/calc/Draw etc icon to desktop

Actual Results:
A .desktop file is created for LO or one of it's components. The .desktop file is registered as belonging to root and not user.

Expected Results:
The created .desktop file should belong to the user and not be registered as belonging to root.


Reproducible: Always


User Profile Reset: No



Additional Info:
Comment 1 alucardnoir 2019-05-09 16:01:58 UTC
Ok, so as a comment on this I'd like to quote what one of the devs on Solus told me:

"The issue with LibreOffice desktop files being owned as root is the result of LibreOffice actually having a build system which installs the desktop files into the completely incorrect location, which is /usr/lib/libreoffice/share/xdg, then symlinking to /usr/share/applications/. As a result, the desktop file on the desktop is a symlink to that xdg directory, which is owned by root. The correct procedures would be:

File a bug upstream to have the LO desktop files be installed into the correct directory instead of symlinking"

I haven't been on linux in quite a few years so I don't know how right he is, but since he's a member of the core team of an up-and-coming OS I'll take him at his word for now and relay the information he's given me to people that probably do know if he's right or not.
Comment 2 Usama 2019-05-23 15:27:06 UTC
Hello,
Thank you for reporting this issue. I've checked it on my system Ubuntu 16.04 with XCF, the .desktop file was owned by the user not by root.
I've even tested creating a desktop link for /usr/lib/libreoffice/share/xdg/writer.desktop using the command "ln -s" and file was still owned by the user not root. I run Libreoffice as normal user.

Is it possible for you to try to reproduce it on other systems? maybe in a virtual machine

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
Comment 3 alucardnoir 2019-05-24 10:34:45 UTC
Unfortunately I've moved all my machines to just Solus and have no VM experience. I tried a live key of KDE NEON that someone had claimed on the Solus Forums presented the user with the same problem but it doesn't come with LO.

That being said, I have found this forum thread about ubuntu and LO from 2015 that seems to describe this exact problem: https://forum.openoffice.org/en/forum/viewtopic.php?f=16&t=77079

And would also like to add that kyrios123, Solus developer and repo maintainer has already "fixed" the problem in the latest LO package for Solus (as can be seen here: https://dev.getsol.us/D6229 ), so the problem wouldn't even be reproducible in Solus at this point.

Again, all I can contribute is this quote from the currently main Solus dev:

"The issue with LibreOffice desktop files being owned as root is the result of LibreOffice actually having a build system which installs the desktop files into the completely incorrect location, which is /usr/lib/libreoffice/share/xdg, then symlinking to /usr/share/applications/. As a result, the desktop file on the desktop is a symlink to that xdg directory, which is owned by root.The correct procedures would be:

1.File a bug upstream to have the LO desktop files be installed into the correct directory instead of symlinking

2.Updating our package until upstream fixes it to move the contents and potentially reverse the direction of the symlink in the event LO relies on those desktop files being in that xdg directory. "

I am sorry I can not be of more assistance in this matter.
Comment 4 QA Administrators 2019-05-25 02:58:15 UTC Comment hidden (obsolete)
Comment 5 Jean-Baptiste Faure 2020-03-30 06:56:29 UTC
(In reply to alucardnoir from comment #0)
> Description:
> On Solus Budgie, and verified by someone else on KDE Neon,
> (https://discuss.getsol.us/d/779-libreoffice-borked) normally created
> .desktop files for LO belong to root as opposed to the user. This means they
> can't be trusted by normal users and thus be used as desktop icons. This is
> not expected behavior and since it's both distro and DE agnostic seems to
> originate with LO.

Why? It's easy to copy a desktop file and change its proprietary if you want add an icon on your desktop.
> 
> Steps to Reproduce:
> 1.Open a Linux distro with a DE that suports desktop icons.
> 2.Open the menu or a file explorer
> 3.Drag the LO icon, or the Writer/calc/Draw etc icon to desktop

Which LO icon? Where do you take it from?

> 
> Actual Results:
> A .desktop file is created for LO or one of it's components. The .desktop
> file is registered as belonging to root and not user.
> 
> Expected Results:
> The created .desktop file should belong to the user and not be registered as
> belonging to root.

Did you try to do the same thing with the desktop file of another application installed system-wide ?

Set status to NEEDINFO, please set it back to unconfirmed once requested information have been provided.

Best regards. JBF
Comment 6 alucardnoir 2020-03-30 10:23:31 UTC
(In reply to Jean-Baptiste Faure from comment #5)
> Why? It's easy to copy a desktop file and change its proprietary if you want
> add an icon on your desktop.

The created .desktop files belong to root. That means the user need to be logged in as root to be able to do so in the graphical user environment. That's something that is generally discouraged. But I guess that's not a problem if you're mostly a terminal user. I am not so it is a problem for me.

> Which LO icon? Where do you take it from?

In the case of Solus LO icons are to be found in the budgie menu. Installing from the GUI software centre or via terminal though eopkg directly will create working icons in the budgie menu. Solus offers the ability to use desktop icons and to pin icons in a icons task list. This is as simple as drag and dropping or pinning.

This did not work on Solus, and as another user reported on KDE Neon because LO's default .desktop icons are registered as belonging to root as opposed to the user. And here is what the solus dev that diagnosed this said:

"The issue with LibreOffice desktop files being owned as root is the result of LibreOffice actually having a build system which installs the desktop files into the COMPLETELY INCORRECT LOCATION, which is /usr/lib/libreoffice/share/xdg, then symlinking to /usr/share/applications/. As a result, the desktop file on the desktop is a symlink to that xdg directory, which is owned by root. The correct procedures would be:

File a bug upstream to have the LO desktop files be installed into the correct directory instead of symlinking"

You CAN'T change the properties of a file belonging to root unless you are logged in as root or unless you use the terminal with su/sudo. And in the case of something like the budgie taskmenu, that's more hassle then it's worth.

> Did you try to do the same thing with the desktop file of another
> application installed system-wide ?

Yes, and there was no such problem. The problem was diagnosed by the Solus devs that maintain the LO package in their repo and I was sent this way to report it. Since then, the problem has been "solved" by the person maintaining the Lo package for Solus. But that's more of an alteration of the default LO install parameters in Solus then a solution to the bug.

Also, please don't take this the wrong way but I'm frankly surprised anybody on here still cares since it's been close to a year since I made this report.

Frankly all that need to be done is ask to whom do the files in /usr/lib/libreoffice/share/xdg belong to and if that's the correct location for .desktop files to be put in. The solus devs seem to think the files under /usr/lib/ should belong to root, while, as someone else stated on Ubuntu they seem to belong to the user. I unfortunately don't know enough about the Linux file system to be able to tell you who is right. The people that make the OS/distro I was using a year ago and am still using - Solus - seem to think the files there should belong to root and not the user. They also think .desktop files shouldn't be placed where LibreOffice puts them. Since I don't know enough about the linux file system all I can do is foreword to you what they told me. If they're wrong, then this was a Solus problem to begin with and I'm sorry for having wasted your time. If they're not you should probably have someone that knows the linux file system and who develops Distros have a look at how LO is built to see if there are other such problmes.
Comment 7 QA Administrators 2020-03-31 03:30:41 UTC Comment hidden (obsolete)
Comment 8 Buovjaga 2020-05-27 09:31:28 UTC
Discussed with our release manager and he advised to close this as WFM:

"Having symlinks is common practice on linux, nowhere in the spec is it written that they must be plain files. find /usr/share/icons/ -type l |wc -l → 287 links here for example.

Reason why LO uses symlinks is that the packages are relocatable (and by default install to /opt/ - it is not possible to use plain files in another prefix in that case, so the desktop-integration package creates the symlinks)

Distro-packages that change the installations paths are free to change how the desktop files are installed. They don't need to care about being relocatable/only using a single prefix, so no reason for them to keep the symlinks."
Comment 9 Buovjaga 2020-05-27 09:35:59 UTC
"For the user: Press a modifier when copying in the file manager. All filemanagers should have shift of alt toggle or similar to switch between creating a link or a copy (and breaking a link and creating a copy instead)

(If the filemanager manages to create actual files owned by root when using the file-manager as non-root, then /that/ is seriously broken...)"