Version: (using KDE KDE 3.4.0) Installed from: Fedora RPMs OS: Linux In /usr/share/config/kdesktoprc we set-up : [Background Common] CommonDesktop[$i]=true [Desktop0][$i] Wallpaper=/usr/share/backgrounds/images/default.png to make the wallpaper immutable. Users are still able to change their wallpaper: KolourPaint includes options on the file menu to save an image as the wallpaper. If the users logoff and logon again, their wallpaper has reverted to that set in /usr/share/config/kdesktoprc however we expect users to not be able to change their wallpaper at all if the desktop has been locked down.
On Thursday 06 October 2005 23:56, Martin Woolley wrote: > http://bugs.kde.org/show_bug.cgi?id=113969 [...] > Version: (using KDE KDE 3.4.0) > > In /usr/share/config/kdesktoprc we set-up : > > [Background Common] > CommonDesktop[$i]=true > > [Desktop0][$i] > Wallpaper=/usr/share/backgrounds/images/default.png > > to make the wallpaper immutable. > > Users are still able to change their wallpaper: KolourPaint includes > options on the file menu to save an image as the wallpaper. > > If the users logoff and logon again, their wallpaper has reverted to that > set in /usr/share/config/kdesktoprc however we expect users to not be able > to change their wallpaper at all if the desktop has been locked down. I think this might be a kdesktop issue rather than KolourPaint. If the security policy was only enforced in KolourPaint, someone could easily recompile KolourPaint with the security policy taken out. Having said that, if it was enforced in kdesktop, there is nothing stopping a user from compiling their own personal version of kdesktop either... Anyway, enforcing security policy at user level has always seemed mysterious to me. kde-kiosk, what do you think? Thanks, Clarence
Clarence Dang wrote: >I think this might be a kdesktop issue rather than KolourPaint. The fact that restarting kdesktop resets to the original wallpaper proves that the config was not changed. However, there are bugs in both apps: kdesktop should not change the wallpaper. I don't know how KolourPaint told kdesktop to do it (probably via DCOP), but kdesktop should verify whether the change was allowed. KolourPaint should not offer to change it if it can find out that such a change is locked down. >If the security policy was only enforced in KolourPaint, someone could > easily recompile KolourPaint with the security policy taken out. There's no Kiosk security if you can run arbitrary applications, including the compiler or modified versions of the allowed applications. Kiosk is founded on the cooperation of the locked-down applications. Hence why use of non-KDE applications in a Kiosk environment is discouraged. (How do you tell Firefox not to go to certain sites, or OpenOffice.org to respect certain restrictions?)
On Thursday 06 Oct 2005 17:24, Clarence Dang wrote: > I think this might be a kdesktop issue rather than KolourPaint. You are probably correct. I had already raised a bug reporting relating to this in kdesktop, but I was asked to raise another because there are two ways that users can change their wallpaper when the desktop is locked down. One way is to open an image in KolourPaint and use the "Save As Wallpaper" options. The other way users can change the wallpaper is to drag an image from Konqueror file browser to the desktop, and you are presented with an option to change the wallpaper. I feel that these options should be greyed out if the desktop is locked down. > If the security policy was only enforced in KolourPaint, someone could easily > recompile KolourPaint with the security policy taken out. > > Having said that, if it was enforced in kdesktop, there is nothing stopping a > user from compiling their own personal version of kdesktop either... Most of our users can barely even manage to log on let alone recompile applications, so I think we are fairly safe on that front! > Anyway, enforcing security policy at user level has always seemed mysterious > to me. Me too > kde-kiosk, what do you think? Last time I looked at this we couldn't get it to run on our systems. I can't remember what the problem was; I'll have a another look at kde-kiosk some time last next week. Many thanks for your efforts
On Friday 07 October 2005 10:11, Chris Fanning wrote: > I understand that non-KDE apps break the kiosk. Perhpas I could user > konqueror instead of Firefox, buy I can't ask the users not to use > ooffice. We had quite an effort getting them off msoffice, I would not > survive if the were told to change suite again. > > Anyone know any firefox/oofice kiosk tricks? Firefox has its own lockdown framework. I mentioned it before, but this time I'll change the subject so others can find it more easily. ------------ As for Firefox, the KDE toolset has no support for it, but firefox has its own lockdown framework. Search this mailing list's archives for the following recent threads: * [Kde-kiosk] Extra modules for kiosktools * [Kde-kiosk] Alt F4 disable ------------ For OOo I have no idea. Perhaps the kde-ified OOo that SUSE ships is actually also capable of Kiosk restrictions? At least the KIO restrictions on opening files and urls might very well work. Action restrictions and restrictions on launching external commands are harder, did anyone ever investigate this?
> > Users are still able to change their wallpaper: KolourPaint includes > > options on the file menu to save an image as the wallpaper. > > > > If the users logoff and logon again, their wallpaper has reverted to that > > set in /usr/share/config/kdesktoprc however we expect users to not be > > able to change their wallpaper at all if the desktop has been locked > > down. > > I think this might be a kdesktop issue rather than KolourPaint. Yes, kdesktop should enforce the KIOSK restrictions when making changes through the DCOP interface. Ideally KolourPaint shouldn't offer to change the wall paper when the settings are locked down, but it would be very difficult for KolourPaint to know about that unless kdesktop can tell KolourPaint via the kdesktop DCOP interface. Cheers, Waldo
> > kde-kiosk, what do you think? Sorry, I meant I was addressing the "kde-kiosk" mailinglist. > Last time I looked at this we couldn't get it to run on our systems. I can't > remember what the problem was; I'll have a another look at kde-kiosk some > time last next week. Your kdesktoprc change means you are using kde-kiosk right now :) Anyway, I saw your kdesktop bug report #113889 and will get KolourPaint to disable the action once kdesktop gives me an interface.
Reassigning bugs to KolourPaint support email address.
Does this apply to KDE4?
I'm settings this to invalid as the actions to set an image as wallpaper ceased to work since there is plasma in KDE as it does not offer to change the wallpaper via DBUS nor has it the same concept as kdesktop in KDE3. So in the next version of kolourpaint the actions for changing the wallpaper will be removed.
See bug 257989. If the decision is to remove that feature, we can close that.