Re: status of kde/plasma kiosk framework in kf5
; kdialog for now ) and a lot of preconfigured files - but it heavily >relies >>>> on the kiosk framework and a the live usb installation i'm already >using in >>>> my school.. >>>> >>>> i'm just working out the kinks.. it's almost ready to go.. >>>> >>>> wouldn't be possible without you.. so thx again! >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 25.05.2016 16:16, Mag. Weissel Thomas wrote: >>>> >>>> hello everybody.. >>>> >>>> first of all... wow! this list of fixes is awesome.. thank you! >>>> >>>> i have a question about this "hide toolbars" restriction.. >>>> >>>> >>>> as you can see in the following screenshot (testing with dolphin >>>> 16.04.0) >>>> >>>> http://test.xapient.net/STUFF/dolphin.jpg >>>> >>>> i tried to restrict unocking the toolbar (look at the terminal) >>>> also visible in the screenshot is, that "lock toolbar positions" is >not >>>> checked but the handle for moving >>>> the toolbars is hidden.. so it works! although the menu entry to >>>> unlock is still there... >>>> >>>> you can also see that "show toolbar" (rightclick on the toolbar) >and >>>> "Main Toolbar" (rightclick on the menubar) is still visible so >hiding the >>>> toolbar is possible... >>>> i'm a little bit confused because i read what kai wrote and it >seems >>>> that on his installation only the entry in the menubar context menu >is/was >>>> visible.. >>>> are we talking about the same thing here? just checking! >>>> >>>> >>>> i tested: >>>> action/manage activities=false >>>> >>>> and it properly hides all entries to configure activities.. >"Meta+Q" >>>> doesnt open the activities configuration panel either... yay!! >>>> but "Meta+Tab" shows the activity switcher... holding down "Meta" >and >>>> using the mouse on the activity switcher lets me open the configure >>>> dialog.. no configurations are stored so this is not a big >problem.. >>>> >>>> best regards, >>>> thomas >>>> >>>> >>>> >>>> >>>> Am 2016-05-25 um 14:00 schrieb >>>> enterprise-requ...@kde.org: >>>> >>>> Send Enterprise mailing list submissions to >>>> enterpr...@kde.org >>>> >>>> To subscribe or unsubscribe via the World Wide Web, visit >>>> <https://mail.kde.org/mailman/listinfo/enterprise> >>>> https://mail.kde.org/mailman/listinfo/enterprise >>>> or, via email, send a message with subject or body 'help' to >>>> enterprise-requ...@kde.org >>>> >>>> You can reach the person managing the list at >>>> enterprise-ow...@kde.org >>>> >>>> When replying, please edit your Subject line so it is more specific >>>> than "Re: Contents of Enterprise digest..." >>>> >>>> >>>> Today's Topics: >>>> >>>> 1. Re: status of kde/plasma kiosk framework in kf5 (Kai Uwe >Broulik) >>>> >>>> >>>> >-- >>>> >>>> Message: 1 >>>> Date: Wed, 25 May 2016 11:22:32 +0200 >>>> From: Kai Uwe Broulik > >>>> >>>> To: Plasma >>>> ," enterpr...@kde.org" >>>> >>>> Subject: Re: status of kde/plasma kiosk framework in kf5 >>>> Message-ID: >>>> >>>> Content-Type: text/plain; charset=utf-8 >>>> >>>> Hi Thomas, >>>> >>>> just wanted to give you a quick update. I have just merged the last >>>> patch of our big kiosk fixes pile. >>>> >>>> The following fixes will land in the next Plasma and/or kde >frameworks >>>> release : >>>> >>>> * Leave option in desktop toolbox honors kiosk restriction >>>> * KRunner will be completely disabled (eg won't start at all) when >>>> restricted, so you can't bypass that by calling over DBus directly >>>> * Typing on empty desktop will not try to call krunner if >restricted >>>> * krunner history will be disabled if lineedit_text_completion is >>>> restricted >>>> * Kickoff favorites cannot be rearranged/added/removed when >>>> unlockedDesktop is restricted >>>> * Kickoff applications cannot be edited or added as launcher to >task bar >>>> when unlockedDesktop is restricted, the "edit applications" context >menu >>>> will also be hidden then >>>> * most applets now won't offer context menu entries about modules >>>> restricted via kde control module restrictions. Clicking would >already not >>>> do anything as we already block launching them but we now avoid a >dead menu >>>> entry >>>> * right-clicking menu bar can no longer bypass "hide toolbars" >>>> restriction >>>> >>>> (Hope I didn't forget anything) >>>> >>>> As for the always-shown Activities entry, can you try whether >>>> action/manage activities=false (note the space) works? I'm not sure >if we >>>> handle spaces there properly. >>>> >>>> David is also currently patching all of our applications so they >use the >>>> kiosk keys in the documentation (most erroneously used action/ >prefix for >>>> everything). >>>> >>>> If you have any further questions or problems, don't hesitate to >ask, >>>> we're happy to help you. >>>> >>>> Kai Uwe >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Subject: Digest Footer >>>> >>>> ___ >>>> Enterprise mailing list >>>> enterpr...@kde.org >>>> https://mail.kde.org/mailman/listinfo/enterprise >>>> >>>> >>>> -- >>>> >>>> End of Enterprise Digest, Vol 3, Issue 11 >>>> * >>>> >>>> >>>> >>>> >>> >>
Re: status of kde/plasma kiosk framework in kf5
gt;>> >>> >>> these are the current restrictions: >>> >>> -- >>> >>> [KDE Action Restrictions][$i] >>> >>> action/switch_user=false >>> action/lock_screen=false >>> action/logout=false >>> action/kwin_rmb=false >>> >>> action/plasma/containment_actions=false >>> >>> action/run_command=false >>> action/options_show_toolbar=false >>> plasma/plasmashell/unlockedDesktop=false >>> plasma/allow_configure_when_locked=false >>> plasma-desktop/add_activities=false >>> unlockedDesktop=false >>> logout=false >>> movable_toolbars=false >>> run_command=false >>> start_new_session=false >>> >>> shell_access=false >>> -- >>> >>> >>> I also found out that restricting the user from entering any other >>> folder than $home (kde url restricitons) is working very well for typical >>> kde applications. >>> >>> libreoffice (even when using the kde file open dialogs - libreoffice kde >>> integration ) still allows to enter any folder you like.. >>> >>> >>> i also kinda hacked my own secure environment where shell access is not >>> allowed by placing a .desktop file in .local/share/kservices5/ServiceMenus/ >>> that allows me to open a terminal in the current folder ^^ >>> >>> dolphin shouldn't allow this.. right? >>> >>> ___ >>> >>> [Desktop Entry] >>> >>> Type=Service >>> >>> Icon=konsole >>> >>> Actions=openterminal >>> >>> X-KDE-Priority=TopLevel >>> >>> ServiceTypes=KonqPopupMenu/Plugin,inode/directory,inode/directory-locked >>> >>> >>> [Desktop Action openterminal] >>> >>> Exec=/usr/bin/konsole --workdir %U >>> >>> Icon=konsole >>> >>> Name=Open Terminal Here >>> >>> __ >>> >>> >>> >>> i even placed an xorg.conf file to supress opening ttys (works as >>> expected) but this little desktop file above did the job :-) >>> >>> __ >>> >>> Section "ServerFlags" >>> >>> Option "DontVTSwitch" "true" >>> >>> EndSection >>> >>> __ >>> >>> >>> >>> Should i make a bug report out of this ? >>> >>> Getting "dolphins" places panel locked too when other toolbars are >>> locked - is this a featurerequest or a bugreport? >>> >>> it is really hard to lockdown a system completely.. if i'm done with >>> it i'm definitely going to write an extensive howto and a little program :-) >>> >>> thank you very much in advance. >>> >>> thomas w. >>> >>> >>> PS: i am working on a plasma based "secure exam environment" (for >>> austrian schools) which i'm going to present at the "day of digital >>> education" at klagenfurt's university in 2 months. >>> >>> nothing special...just a few shellscripts with a small UI (most of it is >>> kdialog for now ) and a lot of preconfigured files - but it heavily relies >>> on the kiosk framework and a the live usb installation i'm already using in >>> my school.. >>> >>> i'm just working out the kinks.. it's almost ready to go.. >>> >>> wouldn't be possible without you.. so thx again! >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On 25.05.2016 16:16, Mag. Weissel Thomas wrote: >>> >>> hello everybody.. >>> >>> first of all... wow! this list of fixes is awesome.. thank you! >>> >>> i have a question about this "hide toolbars" restriction.. >>> >>> >>> as you can see in the following screenshot (testing with dolphin >>> 16.04.0) >>> >>> http://test.xapient.net/STUFF/dolphin.jpg >>> >>> i tried to restrict unocking the toolbar (look at the terminal) >>> also visible in the screenshot is, that "lock toolbar positions" is not >>> checked but the handle for moving >>> the toolbars is hidden.. so it works! although
Re: status of kde/plasma kiosk framework in kf5
> __ >> >> Section "ServerFlags" >> >> Option "DontVTSwitch" "true" >> >> EndSection >> >> __ >> >> >> >> Should i make a bug report out of this ? >> >> Getting "dolphins" places panel locked too when other toolbars are locked >> - is this a featurerequest or a bugreport? >> >> it is really hard to lockdown a system completely.. if i'm done with it >> i'm definitely going to write an extensive howto and a little program :-) >> >> thank you very much in advance. >> >> thomas w. >> >> >> PS: i am working on a plasma based "secure exam environment" (for >> austrian schools) which i'm going to present at the "day of digital >> education" at klagenfurt's university in 2 months. >> >> nothing special...just a few shellscripts with a small UI (most of it is >> kdialog for now ) and a lot of preconfigured files - but it heavily relies >> on the kiosk framework and a the live usb installation i'm already using in >> my school.. >> >> i'm just working out the kinks.. it's almost ready to go.. >> >> wouldn't be possible without you.. so thx again! >> >> >> >> >> >> >> >> >> >> >> On 25.05.2016 16:16, Mag. Weissel Thomas wrote: >> >> hello everybody.. >> >> first of all... wow! this list of fixes is awesome.. thank you! >> >> i have a question about this "hide toolbars" restriction.. >> >> >> as you can see in the following screenshot (testing with dolphin >> 16.04.0) >> >> http://test.xapient.net/STUFF/dolphin.jpg >> >> i tried to restrict unocking the toolbar (look at the terminal) >> also visible in the screenshot is, that "lock toolbar positions" is not >> checked but the handle for moving >> the toolbars is hidden.. so it works! although the menu entry to unlock >> is still there... >> >> you can also see that "show toolbar" (rightclick on the toolbar) and >> "Main Toolbar" (rightclick on the menubar) is still visible so hiding the >> toolbar is possible... >> i'm a little bit confused because i read what kai wrote and it seems that >> on his installation only the entry in the menubar context menu is/was >> visible.. >> are we talking about the same thing here? just checking! >> >> >> i tested: >> action/manage activities=false >> >> and it properly hides all entries to configure activities.. "Meta+Q" >> doesnt open the activities configuration panel either... yay!! >> but "Meta+Tab" shows the activity switcher... holding down "Meta" and >> using the mouse on the activity switcher lets me open the configure >> dialog.. no configurations are stored so this is not a big problem.. >> >> best regards, >> thomas >> >> >> >> >> Am 2016-05-25 um 14:00 schrieb >> enterprise-requ...@kde.org: >> >> Send Enterprise mailing list submissions to >> enterpr...@kde.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> <https://mail.kde.org/mailman/listinfo/enterprise> >> https://mail.kde.org/mailman/listinfo/enterprise >> or, via email, send a message with subject or body 'help' to >> enterprise-requ...@kde.org >> >> You can reach the person managing the list at >> enterprise-ow...@kde.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Enterprise digest..." >> >> >> Today's Topics: >> >> 1. Re: status of kde/plasma kiosk framework in kf5 (Kai Uwe Broulik) >> >> >> -- >> >> Message: 1 >> Date: Wed, 25 May 2016 11:22:32 +0200 >> From: Kai Uwe Broulik >> >> To: Plasma >> ," enterpr...@kde.org" >> >> Subject: Re: status of kde/plasma kiosk framework in kf5 >> Message-ID: >> >> Content-Type: text/plain; charset=utf-8 >> >> Hi Thomas, >> >> just wanted to give you a quick update. I have just merged the last patch >> of our big kiosk fixes pile. >> >> The following fixes will land in the next Plasma and/or kde frameworks >> release : >> >> * Leave option in desktop toolbox honors kiosk restriction >> * KRunner will be completely disabled (eg won't start at all) when >> restricted, so you can't bypass that by calling over DBus directly >> * Typing on empty desktop will not try to call krunner if restricted >> * krunner history will be disabled if lineedit_text_completion is >> restricted >> * Kickoff favorites cannot be rearranged/added/removed when >> unlockedDesktop is restricted >> * Kickoff applications cannot be edited or added as launcher to task bar >> when unlockedDesktop is restricted, the "edit applications" context menu >> will also be hidden then >> * most applets now won't offer context menu entries about modules >> restricted via kde control module restrictions. Clicking would already not >> do anything as we already block launching them but we now avoid a dead menu >> entry >> * right-clicking menu bar can no longer bypass "hide toolbars" >> restriction >> >> (Hope I didn't forget anything) >> >> As for the always-shown Activities entry, can you try whether >> action/manage activities=false (note the space) works? I'm not sure if we >> handle spaces there properly. >> >> David is also currently patching all of our applications so they use the >> kiosk keys in the documentation (most erroneously used action/ prefix for >> everything). >> >> If you have any further questions or problems, don't hesitate to ask, >> we're happy to help you. >> >> Kai Uwe >> >> >> >> >> -- >> >> Subject: Digest Footer >> >> ___ >> Enterprise mailing list >> enterpr...@kde.org >> https://mail.kde.org/mailman/listinfo/enterprise >> >> >> -- >> >> End of Enterprise Digest, Vol 3, Issue 11 >> * >> >> >> >> >
Re: status of kde/plasma kiosk framework in kf5
nd a lot of preconfigured files - but it heavily relies > on the kiosk framework and a the live usb installation i'm already using in > my school.. > > i'm just working out the kinks.. it's almost ready to go.. > > wouldn't be possible without you.. so thx again! > > > > > > > > > > > On 25.05.2016 16:16, Mag. Weissel Thomas wrote: > > hello everybody.. > > first of all... wow! this list of fixes is awesome.. thank you! > > i have a question about this "hide toolbars" restriction.. > > > as you can see in the following screenshot (testing with dolphin 16.04.0) > > http://test.xapient.net/STUFF/dolphin.jpg > > i tried to restrict unocking the toolbar (look at the terminal) > also visible in the screenshot is, that "lock toolbar positions" is not > checked but the handle for moving > the toolbars is hidden.. so it works! although the menu entry to unlock > is still there... > > you can also see that "show toolbar" (rightclick on the toolbar) and "Main > Toolbar" (rightclick on the menubar) is still visible so hiding the toolbar > is possible... > i'm a little bit confused because i read what kai wrote and it seems that > on his installation only the entry in the menubar context menu is/was > visible.. > are we talking about the same thing here? just checking! > > > i tested: > action/manage activities=false > > and it properly hides all entries to configure activities.. "Meta+Q" > doesnt open the activities configuration panel either... yay!! > but "Meta+Tab" shows the activity switcher... holding down "Meta" and > using the mouse on the activity switcher lets me open the configure > dialog.. no configurations are stored so this is not a big problem.. > > best regards, > thomas > > > > > Am 2016-05-25 um 14:00 schrieb > enterprise-requ...@kde.org: > > Send Enterprise mailing list submissions to > enterpr...@kde.org > > To subscribe or unsubscribe via the World Wide Web, visit > <https://mail.kde.org/mailman/listinfo/enterprise> > https://mail.kde.org/mailman/listinfo/enterprise > or, via email, send a message with subject or body 'help' to > enterprise-requ...@kde.org > > You can reach the person managing the list at > enterprise-ow...@kde.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Enterprise digest..." > > > Today's Topics: > > 1. Re: status of kde/plasma kiosk framework in kf5 (Kai Uwe Broulik) > > > -- > > Message: 1 > Date: Wed, 25 May 2016 11:22:32 +0200 > From: Kai Uwe Broulik > > To: Plasma > ," enterpr...@kde.org" > > Subject: Re: status of kde/plasma kiosk framework in kf5 > Message-ID: > > Content-Type: text/plain; charset=utf-8 > > Hi Thomas, > > just wanted to give you a quick update. I have just merged the last patch > of our big kiosk fixes pile. > > The following fixes will land in the next Plasma and/or kde frameworks > release : > > * Leave option in desktop toolbox honors kiosk restriction > * KRunner will be completely disabled (eg won't start at all) when > restricted, so you can't bypass that by calling over DBus directly > * Typing on empty desktop will not try to call krunner if restricted > * krunner history will be disabled if lineedit_text_completion is > restricted > * Kickoff favorites cannot be rearranged/added/removed when > unlockedDesktop is restricted > * Kickoff applications cannot be edited or added as launcher to task bar > when unlockedDesktop is restricted, the "edit applications" context menu > will also be hidden then > * most applets now won't offer context menu entries about modules > restricted via kde control module restrictions. Clicking would already not > do anything as we already block launching them but we now avoid a dead menu > entry > * right-clicking menu bar can no longer bypass "hide toolbars" restriction > > (Hope I didn't forget anything) > > As for the always-shown Activities entry, can you try whether > action/manage activities=false (note the space) works? I'm not sure if we > handle spaces there properly. > > David is also currently patching all of our applications so they use the > kiosk keys in the documentation (most erroneously used action/ prefix for > everything). > > If you have any further questions or problems, don't hesitate to ask, > we're happy to help you. > > Kai Uwe > > > > > -- > > Subject: Digest Footer > > ___ > Enterprise mailing list > enterpr...@kde.org > https://mail.kde.org/mailman/listinfo/enterprise > > > -- > > End of Enterprise Digest, Vol 3, Issue 11 > * > > > >
Re: status of kde/plasma kiosk framework in kf5
Hi, On 10.12.2016 21:57, David Faure wrote: > Is this a bug? Should KDesktopFile::isAuthorizedDesktopFile refuse executing > files from $HOME, even in standard locations like > ~/.local/share/applications, I do not think this is a bug, but enterprise environments have sometimes the requirement to lock down the system via configuration. I know, this is not very nice for the maintainer to maintain several usecases. But the possibility to completely configure KDE to our needs was the reason to go with it. :-) > if run_desktop_files is not authorized? Or do we need a different KIOSK > setting > for this because there are use cases for both? There are several usecases/requirements if i may chime in =) Ours would go even further: 1. It is not possible to execute .desktop files which reside in user-controlled-places at all. This is the case if we do not want almost any modification and a tightly restricted environment for public computers. 2. It is possible for users to have .desktop-files in user-controlled-places for execution, BUT these desktop files may only call programs in system-paths without any arguments or parameters. This is the case if we want that users CAN place desktop-files of their standard-programs like email or office on their desktop, but it should not be possible to create a desktop file which executes a nc-onliner which scans your system and pushes the result to an http-host. so, like /usr/bin/loffice can be started, but stuff like "date && for i in $(seq 250 254) ; do ping -c 1 "192.168.178.$i" >> file ; done && scp file user@remotehost" is not possible to execute. > (1) see KDesktopFile::isAuthorizedDesktopFile in kconfig > (2) see krun.cpp in kio > (3) see kpropertiesdialog.cpp in kio. Hmm, there's possible another bug > there, > the permissions dialog always appears, allowing people to make desktop files > executable, what is blocked by run_desktop_files is the desktop-files-plugin, > i.e. modifying the Exec line. IMO there are use cases for the already existing restrictions too, since typically we sometimes have not the possibility to lockdown the system entirely outside of KDE. For example, you sometimes cannot mount /home non-executable since there is 3rd-party-crap like Cisco Anyconnect which downloads stuff from the CISCO-vpn-server into YOUR HOME and executes it with root-permissions(!). I feel there is a permission matrix somewhere in that jungle of restriction possibilities... Yours, Dennis
Re: status of kde/plasma kiosk framework in kf5
On mercredi 7 décembre 2016 15:13:02 CET David Edmundson wrote: > > > i also kinda hacked my own secure environment where shell access is not > > > > allowed by placing a .desktop file in > > .local/share/kservices5/ServiceMenus/ > > that allows me to open a terminal in the current folder ^^ > > > > > dolphin shouldn't allow this.. right? > > > > Konsole's desktop file has a key X-KDE-AuthorizeAction=shell_access that > > tells klauncher to refuse to start it when such restriction is in effect. > > > > I'll cc David Faure as KIO master whether he knows how to prevent the > > system from picking up custom applications and services in the user's > > home. > > I thought that the .desktop files needed to be marked executable but that > > doesn't seem to be the case. David? Maybe "run_desktop_files" restriction > > helps here? > > > > We have the key > > run_desktop_files > > This should prevent loading any .desktop files in .local Not exactly. It prevents executing application desktop files from random places like $HOME/Desktop even when they are marked as executable (1), and it prevents the messagebox offering to make the file executable, from appearing if it's not (2), as well as preventing the user from using the properties dialog to make desktop files executable (3). But any desktop file that is in a standard path for app desktop files is allowed (see KDesktopFile::isAuthorizedDesktopFile). This includes ~/.local/share/applications and ~/.local/share/kservices5/ServiceMenus/. The security idea behind this is to prevent desktop files masquerading as "normal files" and executing random commands when the user thinks he's just opening a file. But if the user installs a file into ~/.local/share/applications or indeed ~/.local/share/kservices5/ServiceMenus/ then he/she should expect that file to be executed, so in the non-kiosk case, this should be OK. Given the way that KDesktopFile::isAuthorizedDesktopFile is written, the kiosk setting run_desktop_files is currently only about files *outside* standard dirs, so it won't help for ServiceMenus. Is this a bug? Should KDesktopFile::isAuthorizedDesktopFile refuse executing files from $HOME, even in standard locations like ~/.local/share/applications, if run_desktop_files is not authorized? Or do we need a different KIOSK setting for this because there are use cases for both? (1) see KDesktopFile::isAuthorizedDesktopFile in kconfig (2) see krun.cpp in kio (3) see kpropertiesdialog.cpp in kio. Hmm, there's possible another bug there, the permissions dialog always appears, allowing people to make desktop files executable, what is blocked by run_desktop_files is the desktop-files-plugin, i.e. modifying the Exec line. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
Re: status of kde/plasma kiosk framework in kf5
> > > > i also kinda hacked my own secure environment where shell access is not > allowed by placing a .desktop file in .local/share/kservices5/ServiceMenus/ > that allows me to open a terminal in the current folder ^^ > > dolphin shouldn't allow this.. right? > > Konsole's desktop file has a key X-KDE-AuthorizeAction=shell_access that > tells klauncher to refuse to start it when such restriction is in effect. > > I'll cc David Faure as KIO master whether he knows how to prevent the > system from picking up custom applications and services in the user's home. > I thought that the .desktop files needed to be marked executable but that > doesn't seem to be the case. David? Maybe "run_desktop_files" restriction > helps here? > > We have the key run_desktop_files This should prevent loading any .desktop files in .local (in theory at least) David
Re: status of kde/plasma kiosk framework in kf5
Am 07.12.2016 um 10:46 schrieb Kai Uwe Broulik: > Even if the entries still show up in the context menu when you restricted > them (which would be a bug you should report) kcmshell will still refuse to > open it, so it should be purely cosmetical then. > > I *think* the network editor, not being a regular system settings module, > cannot currently be restricted. :/ Needs to be figured out. If you talk about the network editor for the networkmanagement-plasma/networkmanager, you can restrict the networkmanager directly Either with polkit, this is done like it is described in https://ubuntuforums.org/showthread.php?t=2141331 or with networkmanager itself. For this, You would have to define a network-connection and with "nmcli general permissions" you can see the current configuration and restrict modification to a connection (only stop/start/restart it for example). This is than written down in /etc/networkmanager/system-connection/connectionname where users and groups are specified which are allowed to edit/start/stop connections :)
Re: status of kde/plasma kiosk framework in kf5
On Wednesday 07 December 2016 10:46:29 Kai Uwe Broulik wrote: > Even if the entries still show up in the context menu when you restricted > them (which would be a bug you should report) kcmshell will still refuse to > open it, so it should be purely cosmetical then. > > I *think* the network editor, not being a regular system settings module, > cannot currently be restricted. :/ Needs to be figured out. iirc it was recently ported to a kcm, so in future versions this shouldn't be a problem? -- Marco Martin
Re: status of kde/plasma kiosk framework in kf5
Hi Thomas, good to hear back from you! > - Menu for "Edit Applications" in the launcher called "Anwendungsübersicht" > and "Anwendungsmenü" (its working in "Anwendungs-Starter") That was an oversight, I just uploaded a patch to fix this :) The others are just shortcuts to system settings modules. You can use the [KDE Control Module Restrictions] section in kdeglobals, for instance: device_automounter_kcm.desktop=false (You can use kcmshell5 --list to find out the names, there's no extensive documented list on what applet uses which, unfortunately) Even if the entries still show up in the context menu when you restricted them (which would be a bug you should report) kcmshell will still refuse to open it, so it should be purely cosmetical then. I *think* the network editor, not being a regular system settings module, cannot currently be restricted. :/ Needs to be figured out. > libreoffice (even when using the kde file open dialogs - libreoffice kde > integration ) still allows to enter any folder you like.. This is somewhat to be expected as KIOSK only operates on KIO (KDE's own IO Layer). I think you need to use SELinux or AppArmor for that? I'm not an expert in that, though. > i also kinda hacked my own secure environment where shell access is not > allowed by placing a .desktop file in .local/share/kservices5/ServiceMenus/ > that allows me to open a terminal in the current folder ^^ > dolphin shouldn't allow this.. right? Konsole's desktop file has a key X-KDE-AuthorizeAction=shell_access that tells klauncher to refuse to start it when such restriction is in effect. I'll cc David Faure as KIO master whether he knows how to prevent the system from picking up custom applications and services in the user's home. I thought that the .desktop files needed to be marked executable but that doesn't seem to be the case. David? Maybe "run_desktop_files" restriction helps here? Also, I bet a user can still launch xterm even with shell_access. Problem about KIOSK is that it's really only enforced be KDE stuff, so again: perhaps have a look at SELinux / AppArmor to make sure everyone plays well ;) > Getting "dolphins" places panel locked too when other toolbars are locked - > is this a featurerequest or a bugreport? I don't fully understand, which restriction does what exactly to the panel in Dolphin? > if i'm done with it i'm definitely going to write an extensive howto and a > little program :-) Looking forward to it! > PS: i am working on a plasma based "secure exam environment" (for austrian > schools) which i'm going to present at the "day of digital education" at > klagenfurt's university in 2 months. Sounds interesting, looking forward to hearing your report how it went. We're glad you've chosen Plasma for this challenge! > most of it is kdialog for now We could surely help you make it prettier than that :) Thanks slot for your stress tests and feedback, Kai Uwe
Re: status of kde/plasma kiosk framework in kf5
olphin.jpg> >> >> i tried to restrict unocking the toolbar (look at the terminal) >> also visible in the screenshot is, that "lock toolbar positions" is >> not checked but the handle for moving >> the toolbars is hidden.. so it works! although the menu entry to >> unlock is still there... >> >> you can also see that "show toolbar" (rightclick on the toolbar) and >> "Main Toolbar" (rightclick on the menubar) is still visible so hiding >> the toolbar is possible... >> i'm a little bit confused because i read what kai wrote and it seems >> that on his installation only the entry in the menubar context menu >> is/was visible.. >> are we talking about the same thing here? just checking! >> >> >> i tested: >> action/manage activities=false >> >> and it properly hides all entries to configure activities.. "Meta+Q" >> doesnt open the activities configuration panel either... yay!! >> but "Meta+Tab" shows the activity switcher... holding down "Meta" and >> using the mouse on the activity switcher lets me open the configure >> dialog.. no configurations are stored so this is not a big problem.. >> >> best regards, >> thomas >> >> >> >> >> Am 2016-05-25 um 14:00 schrieb >> <mailto:enterprise-requ...@kde.org>enterprise-requ...@kde.org: >>> Send Enterprise mailing list submissions to >>> <mailto:enterpr...@kde.org>enterpr...@kde.org >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> >>> <https://mail.kde.org/mailman/listinfo/enterprise>https://mail.kde.org/mailman/listinfo/enterprise >>> >>> or, via email, send a message with subject or body 'help' to >>> <mailto:enterprise-requ...@kde.org>enterprise-requ...@kde.org >>> >>> You can reach the person managing the list at >>> <mailto:enterprise-ow...@kde.org>enterprise-ow...@kde.org >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of Enterprise digest..." >>> >>> >>> Today's Topics: >>> >>> 1. Re: status of kde/plasma kiosk framework in kf5 (Kai Uwe Broulik) >>> >>> >>> -- >>> >>> Message: 1 >>> Date: Wed, 25 May 2016 11:22:32 +0200 >>> From: Kai Uwe >>> Broulik<mailto:k...@privat.broulik.de> >>> To: Plasma<mailto:plasma-devel@kde.org>," >>> <mailto:enterpr...@kde.org>enterpr...@kde.org" >>> <mailto:enterpr...@kde.org> >>> Subject: Re: status of kde/plasma kiosk framework in kf5 >>> Message-ID: >>> <mailto:e1b5wtm-000269...@smtprelay03.ispgateway.de> >>> Content-Type: text/plain; charset=utf-8 >>> >>> Hi Thomas, >>> >>> just wanted to give you a quick update. I have just merged the last >>> patch of our big kiosk fixes pile. >>> >>> The following fixes will land in the next Plasma and/or kde >>> frameworks release : >>> >>> * Leave option in desktop toolbox honors kiosk restriction >>> * KRunner will be completely disabled (eg won't start at all) when >>> restricted, so you can't bypass that by calling over DBus directly >>> * Typing on empty desktop will not try to call krunner if restricted >>> * krunner history will be disabled if lineedit_text_completion is >>> restricted >>> * Kickoff favorites cannot be rearranged/added/removed when >>> unlockedDesktop is restricted >>> * Kickoff applications cannot be edited or added as launcher to task >>> bar when unlockedDesktop is restricted, the "edit applications" >>> context menu will also be hidden then >>> * most applets now won't offer context menu entries about modules >>> restricted via kde control module restrictions. Clicking would >>> already not do anything as we already block launching them but we now >>> avoid a dead menu entry >>> * right-clicking menu bar can no longer bypass "hide toolbars" >>> restriction >>> >>> (Hope I didn't forget anything) >>> >>> As for the always-shown Activities entry, can you try whether >>> action/manage activities=false (note the space) works? I'm not sure >>> if we handle spaces there properly. >>> >>> David is also currently patching all of our applications so they use >>> the kiosk keys in the documentation (most erroneously used action/ >>> prefix for everything). >>> >>> If you have any further questions or problems, don't hesitate to ask, >>> we're happy to help you. >>> >>> Kai Uwe >>> >>> >>> >>> >>> -- >>> >>> Subject: Digest Footer >>> >>> ___ >>> Enterprise mailing list >>> <mailto:enterpr...@kde.org>enterpr...@kde.org >>> https://mail.kde.org/mailman/listinfo/enterprise >>> <https://mail.kde.org/mailman/listinfo/enterprise> >>> >>> >>> -- >>> >>> End of Enterprise Digest, Vol 3, Issue 11 >>> * >> >
Re: status of kde/plasma kiosk framework in kf5
ailto:enterprise-requ...@kde.org>: Send Enterprise mailing list submissions to enterpr...@kde.org <mailto:enterpr...@kde.org> To subscribe or unsubscribe via the World Wide Web, visit https://mail.kde.org/mailman/listinfo/enterprise <https://mail.kde.org/mailman/listinfo/enterprise> or, via email, send a message with subject or body 'help' to enterprise-requ...@kde.org <mailto:enterprise-requ...@kde.org> You can reach the person managing the list at enterprise-ow...@kde.org <mailto:enterprise-ow...@kde.org> When replying, please edit your Subject line so it is more specific than "Re: Contents of Enterprise digest..." Today's Topics: 1. Re: status of kde/plasma kiosk framework in kf5 (Kai Uwe Broulik) ------------------------------ Message: 1 Date: Wed, 25 May 2016 11:22:32 +0200 From: Kai Uwe Broulik <mailto:k...@privat.broulik.de> To: Plasma <mailto:plasma-devel@kde.org>,"enterpr...@kde.org" <mailto:enterpr...@kde.org> <mailto:enterpr...@kde.org> Subject: Re: status of kde/plasma kiosk framework in kf5 Message-ID: <mailto:e1b5wtm-000269...@smtprelay03.ispgateway.de> Content-Type: text/plain; charset=utf-8 Hi Thomas, just wanted to give you a quick update. I have just merged the last patch of our big kiosk fixes pile. The following fixes will land in the next Plasma and/or kde frameworks release : * Leave option in desktop toolbox honors kiosk restriction * KRunner will be completely disabled (eg won't start at all) when restricted, so you can't bypass that by calling over DBus directly * Typing on empty desktop will not try to call krunner if restricted * krunner history will be disabled if lineedit_text_completion is restricted * Kickoff favorites cannot be rearranged/added/removed when unlockedDesktop is restricted * Kickoff applications cannot be edited or added as launcher to task bar when unlockedDesktop is restricted, the "edit applications" context menu will also be hidden then * most applets now won't offer context menu entries about modules restricted via kde control module restrictions. Clicking would already not do anything as we already block launching them but we now avoid a dead menu entry * right-clicking menu bar can no longer bypass "hide toolbars" restriction (Hope I didn't forget anything) As for the always-shown Activities entry, can you try whether action/manage activities=false (note the space) works? I'm not sure if we handle spaces there properly. David is also currently patching all of our applications so they use the kiosk keys in the documentation (most erroneously used action/ prefix for everything). If you have any further questions or problems, don't hesitate to ask, we're happy to help you. Kai Uwe -- Subject: Digest Footer ___ Enterprise mailing list enterpr...@kde.org <mailto:enterpr...@kde.org> https://mail.kde.org/mailman/listinfo/enterprise <https://mail.kde.org/mailman/listinfo/enterprise> -- End of Enterprise Digest, Vol 3, Issue 11 *
Re: status of kde/plasma kiosk framework in kf5
hello plasma devs and community! i'm currently equipping 40 students with bootable flashdrives (kde neon 5.8 lts) and before deploying my fresh and shiny remastered system in all classrooms to (to annoy the teachers ;-) ) i did some tests with the kiosk framework. i stumbled over a small issue while locking toolbars ... in dolphin action/options_show_toolbar=false now makes it impossible to completely remove the toolbar.. thx for that! # 1) but i can still unlock it and move it to the bottom or somewhere else... this is more of a request... # 2) is it possible to make it impossible to unlock the toolbars AND the sidepanels in dolphin ?? #3) a while ago kai uwe wrote that in > 4.7 the option plasma/plasmashell/unlockedDesktop=false will not only prevent changing favorites and other things in the launcher but also hide the "edit applications" context menu.. the context menu is still shown - but dead. i can stil add/remove favorites (i am using the application "menu" (the one with the classic flyout list view) thx in advance! thomas On 25.05.2016 16:16, Mag. Weissel Thomas wrote: hello everybody.. first of all... wow! this list of fixes is awesome.. thank you! i have a question about this "hide toolbars" restriction.. as you can see in the following screenshot (testing with dolphin 16.04.0) http://test.xapient.net/STUFF/dolphin.jpg i tried to restrict unocking the toolbar (look at the terminal) also visible in the screenshot is, that "lock toolbar positions" is not checked but the handle for moving the toolbars is hidden.. so it works! although the menu entry to unlock is still there... you can also see that "show toolbar" (rightclick on the toolbar) and "Main Toolbar" (rightclick on the menubar) is still visible so hiding the toolbar is possible... i'm a little bit confused because i read what kai wrote and it seems that on his installation only the entry in the menubar context menu is/was visible.. are we talking about the same thing here? just checking! i tested: action/manage activities=false and it properly hides all entries to configure activities.. "Meta+Q" doesnt open the activities configuration panel either... yay!! but "Meta+Tab" shows the activity switcher... holding down "Meta" and using the mouse on the activity switcher lets me open the configure dialog.. no configurations are stored so this is not a big problem.. best regards, thomas Am 2016-05-25 um 14:00 schrieb enterprise-requ...@kde.org: Send Enterprise mailing list submissions to enterpr...@kde.org To subscribe or unsubscribe via the World Wide Web, visit https://mail.kde.org/mailman/listinfo/enterprise or, via email, send a message with subject or body 'help' to enterprise-requ...@kde.org You can reach the person managing the list at enterprise-ow...@kde.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Enterprise digest..." Today's Topics: 1. Re: status of kde/plasma kiosk framework in kf5 (Kai Uwe Broulik) ------ Message: 1 Date: Wed, 25 May 2016 11:22:32 +0200 From: Kai Uwe Broulik To: Plasma,"enterpr...@kde.org" Subject: Re: status of kde/plasma kiosk framework in kf5 Message-ID: Content-Type: text/plain; charset=utf-8 Hi Thomas, just wanted to give you a quick update. I have just merged the last patch of our big kiosk fixes pile. The following fixes will land in the next Plasma and/or kde frameworks release : * Leave option in desktop toolbox honors kiosk restriction * KRunner will be completely disabled (eg won't start at all) when restricted, so you can't bypass that by calling over DBus directly * Typing on empty desktop will not try to call krunner if restricted * krunner history will be disabled if lineedit_text_completion is restricted * Kickoff favorites cannot be rearranged/added/removed when unlockedDesktop is restricted * Kickoff applications cannot be edited or added as launcher to task bar when unlockedDesktop is restricted, the "edit applications" context menu will also be hidden then * most applets now won't offer context menu entries about modules restricted via kde control module restrictions. Clicking would already not do anything as we already block launching them but we now avoid a dead menu entry * right-clicking menu bar can no longer bypass "hide toolbars" restriction (Hope I didn't forget anything) As for the always-shown Activities entry, can you try whether action/manage activities=false (note the space) works? I'm not sure if we handle spaces there properly. David is also currently patching all of our applications so they use the kiosk keys i
Re: status of kde/plasma kiosk framework in kf5
On Wed, Jun 8, 2016 at 3:03 AM, Kai Uwe Broulik wrote: > as far as I know a new KIOSK tool is even being worked on right now. > > Might have been part of GSOC or so, I'm not involved in that, though, Thomas > Pfeiffer should know more I think. It was part of Season of KDE 2015, https://quickgit.kde.org/?p=confine.git Thanks -- Bhushan Shah http://bhush9.github.io IRC Nick : bshah on Freenode ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: status of kde/plasma kiosk framework in kf5
Hi, as far as I know a new KIOSK tool is even being worked on right now. Might have been part of GSOC or so, I'm not involved in that, though, Thomas Pfeiffer should know more I think. Cheers, Kai Uwe ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: status of kde/plasma kiosk framework in kf5
hello everybody! i just found this on opensuse.org --> https://software.opensuse.org/package/kiosktool i used "alien" to create a .deb package and installed it without problems on kubuntu 1604 see screenshots :-) http://test.xapient.net/STUFF/kiosk1.png http://test.xapient.net/STUFF/kiosk2.png it was last revisited by hrvoje.senjan at gmail.com in 2013 and somehow ported to kde4 unfortunately the only languages i speak are scriptlanguages like php, js or python so i can't make much out of the c source code an definitely not fix anything myself but.. as far as i see there is not that much to do to make it work with plasma5 .. from a user point of view i've found 3 minor problems so far: 1.) we need to rework the files in ./data/ that contain the action restrictions and other restrictions (for example actions.kiosk or general.kiosk) to reflect the current state of the kiosk framework some of the things there seem to be outdated and others just got fixed or changed in the last 3 weeks ;-) (or added) 2.) make sure that the configuration file "/etc/kde4rc" is renamed to "/etc/kde5rc" 3.) get rid of the weird looking double headlines both in the same font-style ;-) greetings, thomas ps: there was one group missing out of this.. therefore i added this email to kde-ki...@kde.org hello there kde kiosk developers. if you read this i'd love to thank you for what you've done so far and i hope you could help in updating this nice tool to make it work with the newest version of the awesome plasma-desktop and all of it's great applications :-) if you want to read the whole thread: https://mail.kde.org/pipermail/enterprise/2016-May/thread.html sorry for crossposting. Am 2016-05-12 um 15:23 schrieb Marco Martin: On Thursday 12 May 2016 13:57:31 David Edmundson wrote: same reason i disabled all title bar actions in kwin and all keyboardshortcuts.. i don't want anyone to accidentally do something unintended.. OK, I think that might have got lost in the port. containment_context_menu doesn't seem to exist anymore. However, with run_command and logout disabled this menu will be near empty anyway. I'll take a look. as a separate way to just removing every containment action plugin? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: status of kde/plasma kiosk framework in kf5
Hi, > http://test.xapient.net/STUFF/dolphin.jpg The menu on the left is fixed by the last patch that I mentioned. On the right looks like yet another oversight, I just uploaded a patch for review [1] to fix that. Cheers, Kai Uwe [1] https://git.reviewboard.kde.org/r/128014/ ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: status of kde/plasma kiosk framework in kf5
hello everybody.. first of all... wow! this list of fixes is awesome.. thank you! i have a question about this "hide toolbars" restriction.. as you can see in the following screenshot (testing with dolphin 16.04.0) http://test.xapient.net/STUFF/dolphin.jpg i tried to restrict unocking the toolbar (look at the terminal) also visible in the screenshot is, that "lock toolbar positions" is not checked but the handle for moving the toolbars is hidden.. so it works! although the menu entry to unlock is still there... you can also see that "show toolbar" (rightclick on the toolbar) and "Main Toolbar" (rightclick on the menubar) is still visible so hiding the toolbar is possible... i'm a little bit confused because i read what kai wrote and it seems that on his installation only the entry in the menubar context menu is/was visible.. are we talking about the same thing here? just checking! i tested: action/manage activities=false and it properly hides all entries to configure activities.. "Meta+Q" doesnt open the activities configuration panel either... yay!! but "Meta+Tab" shows the activity switcher... holding down "Meta" and using the mouse on the activity switcher lets me open the configure dialog.. no configurations are stored so this is not a big problem.. best regards, thomas Am 2016-05-25 um 14:00 schrieb enterprise-requ...@kde.org: Send Enterprise mailing list submissions to enterpr...@kde.org To subscribe or unsubscribe via the World Wide Web, visit https://mail.kde.org/mailman/listinfo/enterprise or, via email, send a message with subject or body 'help' to enterprise-requ...@kde.org You can reach the person managing the list at enterprise-ow...@kde.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Enterprise digest..." Today's Topics: 1. Re: status of kde/plasma kiosk framework in kf5 (Kai Uwe Broulik) -- Message: 1 Date: Wed, 25 May 2016 11:22:32 +0200 From: Kai Uwe Broulik To: Plasma,"enterpr...@kde.org" Subject: Re: status of kde/plasma kiosk framework in kf5 Message-ID: Content-Type: text/plain; charset=utf-8 Hi Thomas, just wanted to give you a quick update. I have just merged the last patch of our big kiosk fixes pile. The following fixes will land in the next Plasma and/or kde frameworks release : * Leave option in desktop toolbox honors kiosk restriction * KRunner will be completely disabled (eg won't start at all) when restricted, so you can't bypass that by calling over DBus directly * Typing on empty desktop will not try to call krunner if restricted * krunner history will be disabled if lineedit_text_completion is restricted * Kickoff favorites cannot be rearranged/added/removed when unlockedDesktop is restricted * Kickoff applications cannot be edited or added as launcher to task bar when unlockedDesktop is restricted, the "edit applications" context menu will also be hidden then * most applets now won't offer context menu entries about modules restricted via kde control module restrictions. Clicking would already not do anything as we already block launching them but we now avoid a dead menu entry * right-clicking menu bar can no longer bypass "hide toolbars" restriction (Hope I didn't forget anything) As for the always-shown Activities entry, can you try whether action/manage activities=false (note the space) works? I'm not sure if we handle spaces there properly. David is also currently patching all of our applications so they use the kiosk keys in the documentation (most erroneously used action/ prefix for everything). If you have any further questions or problems, don't hesitate to ask, we're happy to help you. Kai Uwe -- Subject: Digest Footer ___ Enterprise mailing list enterpr...@kde.org https://mail.kde.org/mailman/listinfo/enterprise -- End of Enterprise Digest, Vol 3, Issue 11 * ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: status of kde/plasma kiosk framework in kf5
Hi Thomas, just wanted to give you a quick update. I have just merged the last patch of our big kiosk fixes pile. The following fixes will land in the next Plasma and/or kde frameworks release : * Leave option in desktop toolbox honors kiosk restriction * KRunner will be completely disabled (eg won't start at all) when restricted, so you can't bypass that by calling over DBus directly * Typing on empty desktop will not try to call krunner if restricted * krunner history will be disabled if lineedit_text_completion is restricted * Kickoff favorites cannot be rearranged/added/removed when unlockedDesktop is restricted * Kickoff applications cannot be edited or added as launcher to task bar when unlockedDesktop is restricted, the "edit applications" context menu will also be hidden then * most applets now won't offer context menu entries about modules restricted via kde control module restrictions. Clicking would already not do anything as we already block launching them but we now avoid a dead menu entry * right-clicking menu bar can no longer bypass "hide toolbars" restriction (Hope I didn't forget anything) As for the always-shown Activities entry, can you try whether action/manage activities=false (note the space) works? I'm not sure if we handle spaces there properly. David is also currently patching all of our applications so they use the kiosk keys in the documentation (most erroneously used action/ prefix for everything). If you have any further questions or problems, don't hesitate to ask, we're happy to help you. Kai Uwe ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: status of kde/plasma kiosk framework in kf5
El dijous, 19 de maig de 2016, a les 10:39:48 CEST, Kai Uwe Broulik va escriure: > Hi, > > > i tried the toolbars action restriction but... > > ...i still could hide toolbars in dolphin and gwenview for example.. > > what did i do wrong? > > You're referring to right clicking the menu bar? > > Turns out this menu is added automatically by Qt, ie. it's one layer down in > the stack, and it knows nothing about our kiosk framework. Which menu is added by Qt? Can you give me a screenshot of the one you mean? Cheers, Albert > > We'll look into this. > > Cheers, > Kai Uwe > > ___ > Enterprise mailing list > enterpr...@kde.org > https://mail.kde.org/mailman/listinfo/enterprise ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: status of kde/plasma kiosk framework in kf5
On Wednesday, May 18, 2016 10:50:36 PM CEST Mag. Weissel Thomas wrote: > first of all... thank you all so much for your engagement.. i can't say > it in other words than.. you rock! As a Plasma dev just following the work going in, I need to agree: they rock! I'm really impressed with which vigor our Plasma devs hunt down each and every of the usages of KAuthorized and fix the hell out of it. Good job! Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: status of kde/plasma kiosk framework in kf5
Hi, > i tried the toolbars action restriction but... > ...i still could hide toolbars in dolphin and gwenview for example.. > what did i do wrong? You're referring to right clicking the menu bar? Turns out this menu is added automatically by Qt, ie. it's one layer down in the stack, and it knows nothing about our kiosk framework. We'll look into this. Cheers, Kai Uwe ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: status of kde/plasma kiosk framework in kf5
first of all... thank you all so much for your engagement.. i can't say it in other words than.. you rock! i tried the toolbars action restriction but... This can be blocked with: action/options_show_toolbar=false ...i still could hide toolbars in dolphin and gwenview for example.. what did i do wrong? thx again! thomas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: status of kde/plasma kiosk framework in kf5
On Tue, May 17, 2016 at 2:58 PM, Kai Uwe Broulik wrote: > And a follow up on your in-line comments: > > > action/kdesktop_rmb=false # Whether the user can right click > on a file icon on the desktop # this only works with plasma in "folderview" > mode on real files > > Looking at the code this is intentional. It probably just got ported from > Plasma 4 without questioning it, would be easily changeable, though. > > > action/plasma/containment_actions=false # Whether the user can right > click on the desktop to get any actions > > # this only works when the desktop is locked and only for the panel and > the desktop > > # the panel still shows the menu but the menu is dead > > That's a logic error in the code, it bails out when requesting the context > menu if the view is immutable *and* containment_actions is blocked. > > > plasma/allow_configure_when_locked=false# Whether an applet already > added to the desktop can be configured. > > # this still shows a contextmenu with the configure option on applets in > the "panel" > > # those menuentries are dead (this is confusing and should be fixed) > > It means whether to allow configuring a widget when widgets are locked, > I'll fix the dead entries. > > > action/shell_access=false # Whether the user can launch a > shell # it's still possible to open "konsole" ! > > Note thah shell_access also disables the KRunner plug-in that allows > running arbitrary she'll commands. As for Konsole, you probably need to > restrict access to it using other means, as long as a user can launch > arbitrary applications they could also just run xterm which isn't a kde > application and bundled with the XServer by default. > Konsole should be blocked. The konsole .desktop file contains: X-KDE-AuthorizeAction=shell_access KService should be checking that. I'll check if it is. David > > > plasma-desktop/add_activities=false # Whether a new activity can > be added > > # adding activities is not working but not showing the whole sidepanel > would be better > > You still need means of switching activities though? On the other hand the > option should probably be hidden if there is just one (the default) > activity and you aren't allowed to add new ones; this might be tricky > though. You can remove the Activities entry by unchecking it from the > "default menu" "Mouse Actions" in the desktop view setting I think. > > Cheers, > Kai Uwe > > ___ > Enterprise mailing list > enterpr...@kde.org > https://mail.kde.org/mailman/listinfo/enterprise > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: status of kde/plasma kiosk framework in kf5
And a follow up on your in-line comments: > action/kdesktop_rmb=false # Whether the user can right click on a > file icon on the desktop # this only works with plasma in "folderview" mode > on real files Looking at the code this is intentional. It probably just got ported from Plasma 4 without questioning it, would be easily changeable, though. > action/plasma/containment_actions=false # Whether the user can right > click on the desktop to get any actions > # this only works when the desktop is locked and only for the panel and the > desktop > # the panel still shows the menu but the menu is dead That's a logic error in the code, it bails out when requesting the context menu if the view is immutable *and* containment_actions is blocked. > plasma/allow_configure_when_locked=false # Whether an applet already added > to the desktop can be configured. > # this still shows a contextmenu with the configure option on applets in the > "panel" > # those menuentries are dead (this is confusing and should be fixed) It means whether to allow configuring a widget when widgets are locked, I'll fix the dead entries. > action/shell_access=false # Whether the user can launch a shell # > it's still possible to open "konsole" ! Note thah shell_access also disables the KRunner plug-in that allows running arbitrary she'll commands. As for Konsole, you probably need to restrict access to it using other means, as long as a user can launch arbitrary applications they could also just run xterm which isn't a kde application and bundled with the XServer by default. > plasma-desktop/add_activities=false # Whether a new activity can be > added > # adding activities is not working but not showing the whole sidepanel would > be better You still need means of switching activities though? On the other hand the option should probably be hidden if there is just one (the default) activity and you aren't allowed to add new ones; this might be tricky though. You can remove the Activities entry by unchecking it from the "default menu" "Mouse Actions" in the desktop view setting I think. Cheers, Kai Uwe ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: status of kde/plasma kiosk framework in kf5
I tried the toolbar setting. It does correctly block moving the toolbars. At least in the applications I tested. There is still a toggle option still in the menu to "show toolbar". This can be blocked with: action/options_show_toolbar=false It's a bit confusingly worded - you're setting the action to show the show/hide the toolbar to false, which means it will always show the toolbar with no option to hide it. Let me know if that solves the problem you had. David ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: status of kde/plasma kiosk framework in kf5
Hi Thomas, thanks a lot for your feedback! > 1.) configuration panel for activities That's a tricky one as we currently do not have QML bindings for Kiosk but I'll look into this. > 2.) the desktopmenu still shows a "leave" button and ignores action/logout I have a patch for this but we apparently didn't agree on what the "logout" restriction means, IMHO it should also block shutting down / reboot as that's also a way to leave the session... > 3.) the applicationlauncher still lets you configure applications (this could > be destructive) I made a patch that will essentially turn the application menu read-only when the unlocked desktop restriction is in effect [1], or am I overshooting the goal? > 4.) rightclick on systemtray still shows "system tray options" and "panel > options" (bouth menus are dead) Maybe that's already fixed in the new 5.7 system tray implementation, if not I'll have a look > 5.) typing on the desktop still launches the "run command" interface > (klauncher) It's called KRunner nowadays ;) David just fixed that, the entire KRunner interface will now be disabled by turning of run_command, so you cannot bypass that anymore by placing a direct dbus call or so. > 6.) toolbars can still be unlocked and therefore easily hidden (need a way to > prevent unlocking) I looked into kxmlgui (the framework responsible for this) but I failed to find a way to disable this option, needs further investigation. If you have any further suggestions or requirements on locking down or adjusting your Plasma setup don't hesitate to ask! Cheers, Kai Uwe [1] https://phabricator.kde.org/D1609 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: status of kde/plasma kiosk framework in kf5
so... i thoroughly testet all of the following keys... i tried to summarize what they should do or >actually< do.. - action/switch_user=false # Whether switching to another user is allowed - action/lock_screen=false # Whether locking the screen is allowed - action/logout=false # Whether the desktop contextmenu or applicationlauncher show the logout option logout=false # Whether the applicationlauncher shows the logout button #both keys set to false still lets you logout via the desktopmenu (cashew) - action/kwin_rmb=false # Whether the user can show the context menu on window titles. Also affects the context menu on taskbar items - action/kdesktop_rmb=false # Whether the user can right click on a file icon on the desktop # this only works with plasma in "folderview" mode on real files # plasma in "desktop" mode with "folderview widget" still allows rightclick - action/fullscreen=false # Whether gwenview for example can switch to fullscreen - action/plasma/containment_actions=false # Whether the user can right click on the desktop to get any actions # this only works when the desktop is locked and only for the panel and the desktop # the panel still shows the menu but the menu is dead - plasma/plasmashell/unlockedDesktop=false# Whether applets/containments can be added/removed plasma/allow_configure_when_locked=false# Whether an applet already added to the desktop can be configured. # this still shows a contextmenu with the configure option on applets in the "panel" # those menuentries are dead (this is confusing and should be fixed) - movable_toolbars=false # Whether toolbars can be moved # the still can be unlocked and REmoved - which is worse !! - action/run_command=false # Whether krunner can be launched by the context menu run_command=false# Whether krunner can be launched by shortcuts alt+f2 or alt+space #both keys set to false still lets you access "krunner" by typing on the desktop #both keys disable running arbitrary commands like "killall konsole" - action/shell_access=false # Whether the user can launch a shell # it's still possible to open "konsole" ! - action/start_new_session=false # Whether a new session can be started - plasma-desktop/add_activities=false # Whether a new activity can be added # adding activities is not working but not showing the whole sidepanel would be better _ enabling ALL of these restrictions generates an almost locked desktop.. almost.. 1.) the desktopmenu (hamburgermenu) still allows to start the configuration panel for activities 2.) the desktopmenu still shows a "leave" button and ignores action/logout 3.) the applicationlauncher still lets you configure applications (this could be destructive) 4.) rightclick on systemtray still shows "system tray options" and "panel options" (bouth menus are dead) 5.) typing on the desktop still launches the "run command" interface (klauncher) 6.) toolbars can still be unlocked and therefore easily hidden (need a way to prevent unlocking) as workaround (for now) i'm going to use the desktop "tweaks" to hide the misbehaving desktop menu and "sudo chmod -x /usr/bin/kmenuedit" to create another "dead" menuentry.. the only thing i don't know how to prevent is the removal of important toolbars.. i already hear the teachers whining about not being able to "print" or "undo" stuff.. cheers, thomas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: status of kde/plasma kiosk framework in kf5
David Edmundson ha scritto: > Here's my list I spent the evening on from searching the code. When you are done with all the discoveries, could you please update the pages on wikis, like for example: https://userbase.kde.org/KDE_System_Administration#User_.26_Group_Profiles (and related subpages)? -- Luigi ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: status of kde/plasma kiosk framework in kf5
cool... i missed that.. plasma/containment_actions=false #works(1/2) - disables the contextmenu on the desktop so the last one "acitivities" is also gone.. nothing else changed.. systray, applicationlauncher, konsole(starter), still open a context menu.. activities are still configurable via the desktopmenu (cashew) Am 2016-05-12 um 23:42 schrieb enterprise-requ...@kde.org: plasma/containment_actions=false >> > This does still exist, but it got renamed. change it to action/plasma/containment_actions=false ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: status of kde/plasma kiosk framework in kf5
Where are you finding those key values? Here's my list I spent the evening on from searching the code. action/bookmarks | ???. FIXME 0 action/kdesktop_rmb | Whether the user can right click on a file icon on the desktop action/kwin_rmb | Whether the user can show the context menu on window titles. Also affects the context menu on taskbar items action/lock_screen | Whether the user can lock the screen action/logout | Whether the user can logout. See Fixme2 action/plasma/containment_actions | Whether the user can right click on the desktop to get any actions action/run_command | Whether krunner can be launched by alt+space or the context menu *See Fixme1 action/shell_access | Whether the user can launch a shell action/show_lancelot | ?!? ? Why is this in our code at all action/start_new_session | Whether a new session can be started action/switch_user | Whether the user can switch to another existing session. logout | Whether the user can log out. See Fixme2 plasma/allow_configure_when_locked | Whether an applet already added to the desktop can be configured. plasma-desktop/add_activities | Whether a new activity can be added plasma-desktop/scripting_console | Whether a user can launch + run Plasma's script plasma/plasmashell/unlockedDesktop | Whether applets/containments can be added/removed run_command | Whether krunner can launch arbitrary commands. Not to be confused with action/run_command. See Fixme1 FIXME0: It's in folderview code and blocks a menu action "bookmark this file" but I have never seen this feature. FIXME1: action/run_command and run_command are confusing. They start off doing different things as described above but: runners/shell/shellrunner.cpp mixes up action/run_command with the other run_command. FIXME2: Find out what these mean. ksmserver/server.cpp also has a "logout" as opposed to action/logout used elsewhere in the UI. applets/kicker/plugin/systementry.cpp checks for both! I don't know what to use here. I suspect porting error. The outdated docs seem to imply that lock/logout/switch were all kauthorized::authorize and not kauthorized::authorizeKAction - is it better to get closed to Plasma4 or be consistent with the last release of Plasma5? FIXME3: action/editable_desktop_icons It's in #ifdef 0 code. It has a //TODO written above it. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: status of kde/plasma kiosk framework in kf5
hello everybody! i found some time to test several options.. here is what i have so far and i think i found one or two bugs. please comment to the #works(1/2) and #not-working parts.. especially activities and (RE)movable toolbars need a "fix" [KDE Action Restrictions][$i] action/run_command=false#works - contextmenu does not show entry action/lock_screen=false#works - contextmenu does not show entry action/logout=false #works(1/2) - contextmenu and appclicationlauncher do not show the entry/button / hamburgermenu(aka cashew) still shows leave actions/leave=false #NOT-WORKING - hamburger menu still shows the leave option - also tried action/leave (without the s) actions/switch_user=false #NOT-WORKING - application launcher still shows switch-user option and allows to start new session - also tried action/leave (without s) action/kwin_rmb=false #works - kwin titlebar contextmenu is disabled action/fullscreen=false #works - gwenview for example doesn't go to fullscreen anymore plasma/plasmashell/unlockedDesktop=false#works - unable to unlock desktop plasma/allow_configure_when_locked=false#works - widgets are not configurable anymore movable_toolbars=false #works(1/2) - toolbars can be unlocked but not moved... but still REmoved !! run_command=false #works(1/2) - disables shortcuts alt+f2 alt+space but typing on the desktop still brings up krunner ^^ plasma-desktop/add_activities=false #NOT-WORKING - did never work - i also tried plasmashell/add_acitivies and plasma/plasmashell/add_acitivies action/movable_toolbars=false #NOT-WORKING - does nothing because moveable_toolbars already does the job??? action/options_configure_keybinding=false #NOT-WORKING / not necessary because hamburger menu doesn't provide this option anymore ? plasma/containment_actions=false#i don't know what this should do ? with these configurations in place i am still able to add/stop/run activities, logout via the desktop menu (hamburgermenu), configure systemtray and clock, edit applications (applicationlauncher) and i get a contextmenu on the "konsole" starter i placed in the panel .. it says "open a new window" (this is kinda funny because all the other starters are quiet) also i am still able to remove toolbars and for example the places panel.. this renders applications unusable and would be very very important.. so far so good.. i guess i could make the systemtray and the clock immutable in "plasma-org.kde.plasma.desktop-appletsrc" (this would allow the user to open the file and make it configurable again so it's not safe but it would be good enough for me.. could i place a "locked" version of this file in /etc/xdg/ to prevent unlocking? regards, thomas Am 2016-05-12 um 15:23 schrieb Marco Martin: On Thursday 12 May 2016 13:57:31 David Edmundson wrote: same reason i disabled all title bar actions in kwin and all keyboardshortcuts.. i don't want anyone to accidentally do something unintended.. OK, I think that might have got lost in the port. containment_context_menu doesn't seem to exist anymore. However, with run_command and logout disabled this menu will be near empty anyway. I'll take a look. as a separate way to just removing every containment action plugin? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: status of kde/plasma kiosk framework in kf5
On Thursday 12 May 2016 13:57:31 David Edmundson wrote: > > same reason i disabled all title bar actions in kwin and all > > keyboardshortcuts.. i don't want anyone to accidentally do something > > unintended.. > > OK, I think that might have got lost in the port. > containment_context_menu doesn't seem to exist anymore. However, with > run_command and logout disabled this menu will be near empty anyway. > I'll take a look. as a separate way to just removing every containment action plugin? -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: status of kde/plasma kiosk framework in kf5
>That last one should be >plasma/plasmashell/unlockedDesktop=false thank you for spotting that :-) >Maybe, but the documentation is the main part missing, and the tool is only as good as the documentation it's showing. Sorting that should be our first priority. definitely.. we ( probably i ) need to update the documentation .. the docs https://userbase.kde.org/KDE_System_Administration/Kiosk/Introduction Revision as of 22:17, 10 March 2016 by Ochurlaud still mention /share/config/kdesktoprc /share/config/kdeglobals [$i] at the beginning of a file and so on.. On Thu, May 12, 2016 at 2:57 PM, David Edmundson wrote: > > > On Thu, May 12, 2016 at 1:44 PM, Thomas Weissel > wrote: > >> thank you david for your answer and thx to thomas for inviting me to this >> mailinglist and also for linking to plasma-devel :-) >> >> so instead of /etc/kde4/kdeglobals my "action restrictions" go to >> /etc/kde5rc from now on !? >> >> Yes. > >> >> >> >> If you're disabling the right click to block unlocking widgets >> >> i disabled the rightclick action to prevent the context menu from >> showing.. so starting krunner, locking, leaving and so on is not possible >> by using this menu.. >> same reason i disabled all title bar actions in kwin and all >> keyboardshortcuts.. i don't want anyone to accidentally do something >> unintended.. >> >> > OK, I think that might have got lost in the port. > containment_context_menu doesn't seem to exist anymore. However, with > run_command and logout disabled this menu will be near empty anyway. > I'll take a look. > > >> those are my action restrictions >> >> [KDE Action Restrictions][$i] >> movable_toolbars=false >> run_command=false >> action/run_command=false >> action/lock_screen=false >> action/movable_toolbars=false >> action/logout=false >> action/kwin_rmb=false >> action/options_configure_keybinding=false >> action/fullscreen=false >> plasma-desktop/add_activities=false >> plasma/containment_actions=false >> plasma/containment_context_menu=false >> plasma/allow_configure_when_locked=false >> plasma/plasma-desktop/unlockedDesktop=false >> > > That last one should be > plasma/plasmashell/unlockedDesktop=false > > It seems it got renamed. > > > David > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: status of kde/plasma kiosk framework in kf5
On Thu, May 12, 2016 at 1:44 PM, Thomas Weissel wrote: > thank you david for your answer and thx to thomas for inviting me to this > mailinglist and also for linking to plasma-devel :-) > > so instead of /etc/kde4/kdeglobals my "action restrictions" go to > /etc/kde5rc from now on !? > > Yes. > > > >> If you're disabling the right click to block unlocking widgets > > i disabled the rightclick action to prevent the context menu from > showing.. so starting krunner, locking, leaving and so on is not possible > by using this menu.. > same reason i disabled all title bar actions in kwin and all > keyboardshortcuts.. i don't want anyone to accidentally do something > unintended.. > > OK, I think that might have got lost in the port. containment_context_menu doesn't seem to exist anymore. However, with run_command and logout disabled this menu will be near empty anyway. I'll take a look. > those are my action restrictions > > [KDE Action Restrictions][$i] > movable_toolbars=false > run_command=false > action/run_command=false > action/lock_screen=false > action/movable_toolbars=false > action/logout=false > action/kwin_rmb=false > action/options_configure_keybinding=false > action/fullscreen=false > plasma-desktop/add_activities=false > plasma/containment_actions=false > plasma/containment_context_menu=false > plasma/allow_configure_when_locked=false > plasma/plasma-desktop/unlockedDesktop=false > That last one should be plasma/plasmashell/unlockedDesktop=false It seems it got renamed. David ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: status of kde/plasma kiosk framework in kf5
Hi Thomas, thank you for your detailed email! I have added the Plasma mailing list, hoping that somebody on that list can provide feedback, which is probably relevant for others on the enterprise list as well (so please make sure you reply to all, dear Plasma devs :) ). Thanks, Thomas On Mittwoch, 11. Mai 2016 23:25:27 CEST Mag. Weissel Thomas wrote: hello everybody, i'm on my way to deploy about 40 classroom installations of kubuntu/neon with plasma5.6 and so far my first testsuspects (15 students) were amazed by the new plasma5 especially the handling of widgets (long press to configure) and the possibilty to undo changes (for example removing the main panel) saves a lot of lifes :) (and of course the new looks) for the classrooms i strongly depend on the #kiosk framework.. i've played around with it in kde4 and managed to lock down the classroom desktops as much as possible (the prove that this was a success is one school year without any support calls that relate to the user interface) here a small list of what i've done so far: i created a file called "kdeglobals" and placed it in /etc/kde4 -- this directory was read first and userconfigurations read later were ignored [KDE Action Restrictions][$i] movable_toolbars=false run_command=false #disable krunner action/run_command=false #hide action in kontextmenu action/lock_screen=false #hide action screenlock in kontextmenu action/movable_toolbars=false #very important !! action/logout=false action/kwin_rmb=false action/options_configure_keybinding=false action/fullscreen=false #just in case someone doesn't know how to get outathere plasma-desktop/add_activities=false #not working? plasma/containment_actions=false plasma/containment_context_menu=false plasma/allow_configure_when_locked=false plasma/plasma-desktop/unlockedDesktop=false since the /etc/kde4 directory is gone.. WHERE should i put this file ?? --- echo "disabling rightclick on desktop containment" echo -e "$(sed '/RightButton/d' /home/student/.kde/share/config/plasma-desktop-appletsrc)" > /home/student/.kde/share/config/plasma-desktop-appletsrc this config file has moved to ~/.config and was renamed to "plasma-org.kde.plasma.desktop-appletsrc" (seriously???) --- echo "locking desktop" sudo echo -e "[\$i]\n $(cat /home/student/.kde/share/config/plasma-desktop-appletsrc)" > /etc/kde4/plasma-desktop-appletsrc well..first of all the directory /etc/kde4 does not exist anymore.. creating it and placing a kde configfile in it in order to override the userconfig files is not working anymore further placing [$i] at the beginning of the file (which should make everything immutable) leads to a blank desktop -- only the panel containment is there.. everything else is gone.. --- sudo echo -e "[\$i]\n $(cat /home/student/.kde/share/config/plasma-desktoprc)" > /etc/kde4/plasma-desktoprc echo -e "[\$i]\n $(cat /home/student/.kde/share/config/plasma-desktoprc)" > /home/student/.kde/share/config/plasma-desktoprc this file was renamed to plasmashellrc and moved to ~/.config --- echo "removing cashew..." sudo chmod 600 /usr/lib/kde4/plasma_toolbox_desktoptoolbox.so sudo chmod -x /usr/bin/kmenuedit in kde4 this was the only way to get rid of the cashew.. and dissalow editing the menu -- then i removed almost all keyboardshortcuts and kwin titlebar actions resulting in a totally locked down desktop... the only thing that could revive the desktop was a little script (password protected) "unlock desktop" that would delete the content of /etc/kde4 get the backups of the configuration files the "lockdesktop" script created and copy them over the locked files.. killall Xorg will then do the rest.. so here i am.. i already invested hours to find out what the #kiosk framework can do and can not do.. and now i need to start over it seems. there is a website https://userbase.kde.org/KDE_System_Administration/Kiosk/Introduction and this site is so totally out of date - it hurts... also there was a kiosk admin tool in kde3.. wonderful.. could someone please revive this?? WHAT WORKS SO FAR: ## placing [$i] at the end of a section in plasma-org.kde.plasma.desktop-appletsrc like [ActionPlugins][0][$i] MidButton;NoModifier=org.kde.paste RightButton;NoModifier=org.kde.contextmenu wheel:Vertical;NoModifier=org.kde.switchdesktop will change the whole section (after a restart of the desktop) to this : [ActionPlugins][0] MidButton;NoModifier[$i]=org.kde.paste RightButton;NoModifier[$i]=org.kde.contextmenu wheel:Vertical;NoModifier[$i]=org.kde.switchdesktop you will still be able to configure everything for the session but the next time you log in the setting will be undone.. (not quite what i wanted but still usable) i didn't try it for all sections of course.. but for this section it works.. [Containments][1][Applets][21] you may change "favorites"
