Bug 155550 - OOffice is leaking through accounts (this could be security issue)
Summary: OOffice is leaking through accounts (this could be security issue)
Status: RESOLVED NOT A BUG
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-01-12 18:53 UTC by Maciej Pilichowski
Modified: 2008-01-12 20:54 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Maciej Pilichowski 2008-01-12 18:53:43 UTC
Version:            (using KDE KDE 3.5.8)
Installed from:    SuSE RPMs

Start KDE, login, run OOffice-Writer, start new session, login as the same user, run OOWriter, OOImpress, OOCalc. Nothing? Logout. Now you will find all those apps running fine at the first session.

This is bug for sure, but I don't know if this is security issue -- of course in this case the user is the same, but shouldn't memory&data be separated anyway?
Comment 1 Maksim Orlovich 2008-01-12 19:38:37 UTC
OOffice most likely finds a previous process, and activates that.
And no, there is no separation, and that has 0 to do with KDE --- it's the same user, the only thing that's different is the DISPLAY environment variable that tells what user to talk to.

Not a KDE bug, IMHO
Comment 2 Maksim Orlovich 2008-01-12 19:42:46 UTC
Further testing confirms that. OpenOffice bug --- it shares processes across different DISPLAY's
Comment 3 Maciej Pilichowski 2008-01-12 20:05:01 UTC
Maksim, ok, so this is not security issue, but for the rest of this issue -- OOffice behaves nasty, true, but KDE should prevent such things.

Could you please change to it a wish then? Thank you.
Comment 4 Maciej Pilichowski 2008-01-12 20:09:29 UTC
Btw. I reported it to OO bugzilla:
http://www.openoffice.org/issues/show_bug.cgi?id=85194
Comment 5 Maksim Orlovich 2008-01-12 20:13:25 UTC
There is absolutely no sane way KDE can prevent such things.


Comment 6 Maciej Pilichowski 2008-01-12 20:35:05 UTC
A little "cheating" with DISPLAY?

Maksim, I hope you understand me -- imho KDE as desktop environment should protect user from any fancy/malicious/buggy/bad/etc. window behaviour. So if I set policy A there should be now way app would violate it. Like in this case.
Comment 7 Maksim Orlovich 2008-01-12 20:44:57 UTC
You severely overestimate abilities of a DE. What happens is this:

1. You start session #1. That starts X :0, and sets DISPLAY=:0
2. a bunch of apps run, etc.
3. You run OpenOffice. It connects to X :0, since the DISPLAY=:0
4. You start session #2. That starts X :1, sets DISPLAY=:1
5. a bunch of KDE apps, etc. run. They connect to DISPLAY=:1.
6. You try to start OpenOffice. It notices itself already running, and tells
the old copy to open a new window, which it promptly does, using the :0 display. There is no KDE involvement in this step. None. KDE doesn't see anything whatsoever. 

Comment 8 Maciej Pilichowski 2008-01-12 20:50:08 UTC
Could KDE intercept DISPLAY information -- internally keep track of good data, but for any app show it as display 0? Ugly, but since app is allowed to such low level info...
Comment 9 Maksim Orlovich 2008-01-12 20:54:34 UTC
Wouldn't work. The old (and one and only) openoffice process has the socket open to the old X server.