User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.8.0.10) Gecko/20070216 Firefox/1.5.0.10 Build Identifier: I have 25 machines in open public use which absolutely require kiosk mode. I've used it successfully in previous XFCE versions, and am now running 4.3.99 supplied by Vector Linux distro version 5.8 (with latest updates). In 4.3.99, kiosk mode works 'mostly' in the panel, but right click displays the icon/item title where older versions displayed nothing (much preferred!). Worse, for the XFCE panel menu, right click shows and allows "Edit Menu". This exposes information and allows changes which should not happen. The desktop items can also be added/deleted/edited, which also violates the intent of a kiosk mode. Are these issues being addressed? Reproducible: Always Steps to Reproduce: 1. Make a panel with some launchers and a menu 2. Create some desktop stuff. 3. Put above config info where kiosk stuff goes. 4. Invoke kiosk mode (place kioskrc in appropriate place) 5. Login as kiosk-restricted user and right click on any of the above items. Actual Results: Right clicks show panel item title. Right click on xfce-menu shows item title 'Edit Menu' choice. Selecting 'Edit Menu' does indeed launch the menu editor and allows kiosk user to see all (including hidden) menu items and to make and save menu edits. Expected Results: No response to right click at all (as per previous versions) Allowing xfcd-menu edits by kiosk user is a security risk for the system. The issue of desktop items being fully accessable is especially problematic as there appears to be no restrictions whatever on those.
Sorry I mis-identified severity. This is a major show-stopper for deployment of upgraded kiosk systems into the public.
Created attachment 1022 Xfce4-panel fix. Completely hide the menu when Kiosk is enabled.
Created attachment 1023 Extra fix for xfdesktop This patch is not really needed, but maybe when editing the menu is not allowed, but customized the panel is... It's up to you Brian.
Xfce4-panel part for the fix has been committed in trunk and the 4.4 branch.
If you use my coding style, I'll commit it ^_~
Created attachment 1026 xfdesktop fix try 2
(In reply to comment #6) > Created an attachment (id=1026) [details] > xfdesktop fix try 2 Are we expecting that changes to a kiosk config file will require a restart of the panel? Cuz that's what would be needed here...
Well personally I don't see a good reason why not. I mean, you're not enable/disable kiosk all the time and to load the new panel config (after copying it to the xdg folder) you have to restart it anyway...
(In reply to comment #8) > Well personally I don't see a good reason why not. I mean, you're not > enable/disable kiosk all the time and to load the new panel config (after > copying it to the xdg folder) you have to restart it anyway... True; the only time this would be necessary would be when setting up the kiosk mode, maybe trying out a few things. I guess 'xfce4-panel -r' isn't unreasonable to ask. Actually, looking at your patch, it doesn't really fix anything (not that it's not a bad idea). All it does is remove a menu entry. The user may still be able to edit the local user's menu file manually. Though, I just looked at the desktop menu sources, and I don't see what the problem is. The menu code itself checks the kiosk state and should always use the system menu file if the system is locked down. I need to look into this a bit more, though, and I won't have time until this weekend. I'm gonna take this, since it's really an xfdesktop problem, not a panel problem.
Well we already have 'xfce4-panel -r' and it does indeed 'reload' the settings ;).
(In reply to comment #10) > Well we already have 'xfce4-panel -r' and it does indeed 'reload' the settings > ;). Er... that's what I said...
O I though asking Jasper or me for a reload setting for xfce4-panel :), a well. Anyway I think it's better to hide the menu icon when the user is not able/allowed to edit the menu. This is only confusing for both the user and the person who enabled kiosk.
Wow! Thanks for the quick response to this! Will the patches work with 3.99 source? I'm not sure when the distro folks will pick up a later release, but I'd like them to fix the distro version if it can be patched. Since there's some discussion on how desktop and such should handle kiosk mode, I'd like to toss out an idea that I've been considering asking for as an enhancement: Kiosk mode on a per-user basis...i.e. different users could have different setups/panels/etc (just as a normal user now can) but have the setup lockable/unlockable for each user account. I've not pondered all the ways to do this, but the easist would be to let the user account work as normal now, with info stored in the account .config, possibly owned/writable only by a 'kiosk-admin' account. A local kioskrc would be also stored in the individual account .config rather than a single global one so that different levels of locking could be defined per-user. Having such capability would be good for environments where an open terminal could used by different categories of users (e.g. engineering, accounting, personnel, etc.) with each group-specific login (i.e. login as engineering) presenting a session customized and locked-down for only the types of things those users need. I'd be happy to discuss this more if it sounds like it might be reasonable to implement.
You don't need any special help from Xfce to do that. Just set the desktop up the way you want it as that user, and then chown and chmod the config files. Maybe move them out of the user's homedir to something owned by root and use $XDG_CONFIG_HOME and $XDG_CACHE_HOME to point Xfce at the new config locations. For this case, you'd actually leave kiosk mode *off*. At any rate, if you really want special support in Xfce for this, file a separate enhancement request. One bug per bug, please.
(In reply to comment #14) > For this case, you'd actually leave kiosk mode *off*. At any rate, if you > really want special support in Xfce for this, file a separate enhancement > request. I'll do that. But in your reply, while chowning key files and making them unwriteble by the users and turning kiosk off would seemingly allow the *appearance* of various menues, launcher properties, etc, even if any changed weren't actually saved. Better if the user never sees those, especially if a change could be made to the current session but not for later ones.
Can someone remind me what this bug is about? Has this been fixed, or is there still more work to be done?
Sorry for not getting back to this. I committed this to the 4.4 branch. Not sure what we're doing with XfceKiosk in 4.6, though.