Issue 104116 - OOo cannot be started via menu or file-association on KDE 4.3
Summary: OOo cannot be started via menu or file-association on KDE 4.3
Status: CLOSED FIXED
Alias: None
Product: General
Classification: Code
Component: ui (show other issues)
Version: OOo 3.1
Hardware: Unknown Linux, all
: P2 Trivial (vote)
Target Milestone: OOo 3.1.1
Assignee: ivo.hinkelmann
QA Contact: issues@framework
URL: http://www.purinchu.net/wp/2009/02/21...
Keywords: oooqa
Depends on:
Blocks: 101565
  Show dependency tree
 
Reported: 2009-08-09 11:13 UTC by andreschnabel
Modified: 2009-08-25 21:40 UTC (History)
7 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description andreschnabel 2009-08-09 11:13:59 UTC
In KDE 4.3 the handling of .desktop files has been changed for security
considerations.

see http://www.purinchu.net/wp/2009/02/21/desktop-file-security/

Because of this change, OOo cannot be lunched from menue or by opening a file. 

I don't know, when or if this change will be integrated in gnome and the free
desktop standards. 

Anyway - the fix is easy to implement:
- make all the .desktop file in share/xdg executable
 - or -
- make root the owner of all these files.
Comment 1 Olaf Felka 2009-08-10 09:53:36 UTC
CCed: ihi,cloph
Comment 2 Olaf Felka 2009-08-10 14:57:51 UTC
of: as  decided on #oooreleases: target 3.1.1.
Comment 3 ivo.hinkelmann 2009-08-10 15:43:13 UTC
so after installing hundreds of insetsets we saw that:

rpms are fine , debs are :

unxlngi6.pro: all files are installed as root:root
unxlngx6.pro: all files are installed as 786:261 ( what is user so-uprel on the
local build machine

so the supposted fix is to quick n dirty install the desktop files u+x and make
the real fix ( root:root ) for a OOo 3.2

Comment 4 rene 2009-08-10 15:53:15 UTC
> so the supposted fix is to quick n dirty install the desktop files u+x and make
> the real fix ( root:root ) for a OOo 3.2

EXACTLY that I feared. No, don't do that. Don't make not-scripts/not-exeutables +x.

This will force more work on all kinds of people to juust patch that out again
for sanity on the filesystem
Comment 5 ivo.hinkelmann 2009-08-10 16:20:47 UTC
hi,

can anyone of you ( rene, cloph, andre ) enlight me if this problem also occured
with your builded non-sun instsets? if so then this wrong user is not a problem
of our build machine but a general build issue of the unxlngx6.pro 
Comment 6 ivo.hinkelmann 2009-08-10 16:22:54 UTC
by the way ... not only the desktop files had this weird user but the whole
content , the whole /opt/openoffice.org3/*
Comment 7 ivo.hinkelmann 2009-08-10 16:36:27 UTC
ok did myself . A instset on my laptop shows the same behaviour ( build user ) 
Comment 8 rene 2009-08-10 16:38:13 UTC
> can anyone of you ( rene, cloph, andre ) enlight me if this problem also occured
> with your builded non-sun instsets

No, but I don't build installsets out of the OOo buildsystem. (But use the
installer directly to a path), and there's a "fix up all permissions"[1] run
at the end anyway, so...)

[1] which basically does (amonst others) a chown -R 0:0 and a chown
go=rX,u+rw,a-s. Incidentially it already chmod 664s .desktop files, too now that
I look at it's code.... Still +x .desktop files is bad :)
Comment 9 ivo.hinkelmann 2009-08-10 16:58:25 UTC
rene's approch is to build / pack everything in a fakeroot environment so
everything will be root:root . Ingo, any chance we can implement this in
shortest time?
Comment 10 ingo.schmidt-rosbiegal 2009-08-10 17:09:12 UTC
I would like to know if this tasks occurs for RPMs or DEBs or for unxlngi6 or
unxlngx6 ? At the moment we only assume, that there is a problem with 64 Bit
Debian builds (and perhaps with 64 Bit RPM builds).
Comment 11 ivo.hinkelmann 2009-08-10 17:24:15 UTC
ingo, 

-> only deb ,only unxlngx6 
Comment 12 ivo.hinkelmann 2009-08-10 18:49:32 UTC
the problem seems to be the getuid.so from setup_native that does ugly things
but that doesn't work under 64 bit.

Also the LD_PRELOAD seems not to work

I am currently trying to fix it
Comment 13 ivo.hinkelmann 2009-08-10 20:40:02 UTC
LD_PRELOAD 'ing works on suse 9.0 for unxlngi6
and works on ubuntu 9.04 for unxlngx6
but fails on ubuntu 6.06 for unxlngi6 and unxlngx6 ( which is our build machine )

just for the records, the LD_PRELOAD is used to fake / overwrite dpkg-deb stat
getuid calls to return 0 ( root )
Comment 14 ingo.schmidt-rosbiegal 2009-08-11 08:23:32 UTC
ivo,

that sounds reasonable. thank you for your investigations. so unxlngi6 is also
broken?
Comment 15 ivo.hinkelmann 2009-08-11 17:59:45 UTC
everything inside the deb's should be root owned now.

-> fixed in cws sysui311

Anyone willing to test the installation sets? I don't have a KDE 4.3 here ...
Comment 16 ivo.hinkelmann 2009-08-11 18:10:49 UTC
I have uploaded deb instsets here:

http://ooo.services.openoffice.org/pub/OpenOffice.org/cws/upload/sysui311/
Comment 17 andreschnabel 2009-08-11 18:37:55 UTC
downloading right now
Comment 18 andreschnabel 2009-08-11 21:14:19 UTC
verified in cws sysui311 build.

files in deb (32/64bit) installation ar owned by root. starting OOo via menue
work fine in KDE 4.3
Comment 19 thackert 2009-08-13 16:23:43 UTC
Hello andreschnabel, *,
after I got KDE4.3 via dist-upgrade on Debian SID AMD64 today, I could confirm
André's observation ... :( I could not open OOo via menu nor clicked file(s) in
Dolphin ... :(
Thanks to ihi, I tested instset and it works, many thanks. It still works, if I
install the Germanophone files from OOOm310m18 afterwards. So IMHO this issue is
fixed.
HTH
Thomas.
Comment 20 andreschnabel 2009-08-25 21:40:51 UTC
ok in OOo3.1.1RC2 (KDE 4.3 64bit) -> closed