Hello Dear kde mates.

I've been working with KDE kiosk restrictions and i have the following questions/reports that have todo with dolphin and konqueror also.

In Dolphin it seems that there are no permanently way to lock the panels, and hide dot files.

So, in a dolphinrc like this one, the immutable tag is not doing anything.

Code: Select all


[$i]
[MainWindow][$i]
MenuBar[$i]=Disabled
ToolBarsMovable[$i]=Disabled
State=AAAA/wAAAAD9AAAAAwAAAAAAAAB+AAAB9PwCAAAAAvsAAAAWAGYAbwBsAGQAZQByAHMARABvAGMAawAAAAAA/////wAAAAgBAAAF+wAAABQAcABsAGEAYwBlAHMARABvAGMAawEAAAAAAAAB9AAAAFABAAAFAAAAAQAAAAAAAAAA/AIAAAAC+wAAABAAaQBuAGYAbwBEAG8AYwBrAAAAAAD/////AAAACAEAAAX7AAAAFABzAGUAYQByAGMAaABEAG8AYwBrAAAAAAD/////AAAACAEAAAUAAAADAAAAAAAAAAD8AQAAAAH7AAAAGAB0AGUAcgBtAGkAbgBhAGwARABvAGMAawAAAAAA/////wAAAAgBAAAFAAACbQAAAfQAAAAEAAAABAAAAAgAAAAI/AAAAAEAAAACAAAAAQAAABYAbQBhAGkAbgBUAG8AbwBsAEIAYQByAAAAAAD/////AAAAAAAAAAA=


[General][$i]
EditableUrl[$i]=false
GlobalViewProps=true
HomeUrl=~/Desktop
ShowCopyMoveMenu=false
ShowSpaceInfo[$i]=false

[Notification Messages][$i]
ConfirmDelete=true




For instance if you right click on the edge of the left panel, it will open a popup menu where you can even show a konsole_kpart even when you have shell_access=false & action/shell_access=false & action/executeshellcommand=false in kdeglobals!
The other big problem with this popup menu is that you can bring the main toolbar and there you have access to dolphin full configuration.

Konqueror as a replacement kiosked File Manager
What it is working in dolphin and not in konqueror is the option to disable file properties, dolphin is respecting action/properties=false where konqueror is not!

What is not working in both of kde 4.8.X and 4.9 betas is the option to hide dot files and dotted dirs, so there's no way to prevent a user from messing with the .kde settings.



Would apreciate any help/comments.

regards,
hteles

hteles wrote:Hello Dear kde mates.

What is not working in both of kde 4.8.X and 4.9 betas is the option to hide dot files and dotted dirs, so there's no way to prevent a user from messing with the .kde settings.



Would apreciate any help/comments.

regards,
hteles

I've managed to circunvent this by preventing users to see their $HOME by using this:

Code: Select all

[
[KDE URL Restrictions][$i]
rule_1=list,,,,file,,,false
rule_2=list,,,,file,,$HOME/Desktop,true
rule_3=list,,,,file,,$HOME/media/disk,true
rule_4=list,,,,file,,$HOME/.partilha,true
rule_count=4



This associated with forcing konqueror FM to open at ~/Desktop for default prevent users to enter dirs like .kde .ssh .local .config & others, so this solves part of my fears/problems but know i have another problem with this setting.

Ark that uses [KFileDialog Settings] whenever are requested to extract a file fail miserably because it always try to open file:/// instead of ${HOME}.
Any hints to change this behaviour?




regards,
hteles

Unfortunately, we (i.e., developers working on Dolphin) are not familiar with Kiosk, so we can't help much there. If anyone can help to analyze this issue or even suggest a patch, please get in touch with us.

freininghaus wrote:Unfortunately, we (i.e., developers working on Dolphin) are not familiar with Kiosk, so we can't help much there. If anyone can help to analyze this issue or even suggest a patch, please get in touch with us.

Hi there,

i guess that the problem with disabling showing dot files has more todo with kde inner-libs than dolphin itself, but i'm not a programmer. Maybe someone com KDE Core Team is reading this?

What is worth mentioning in dolphin and his lack of kiosk entries it's in another topic that i've put here.
Here is the link viewtopic.php?f=223&t=102789

To resume that topic:
The expected behaviour in KDE since the old days ( KDE 3) is when a program finds a imutabble tag in his config [$i] will prevent that option from being changed by the user, it's just a case of parsing the value and disable the graphical option/context menu. For example, you don't want your users to change mimetypes or let them access all the options in configure menu, that will be a helpdesk nightmare

For instance these three self explanatory examples:
MenuBar[$i]=Disabled
ToolBarsMovable[$i]=Disabled
EditableUrl[$i]=false <-- this can help a user navigate to /etc/ or even edit ~/.kde/share/config/kdeglobals

I'm sad to see that kde 4 as a corporate desktop is still not perfect and very hard to deploy to large organizations. Not a rant but a call for arms. With Windows 2008r2 with it's stinky GPO's you can model all the desktop to the users, we don't want to get behind, do we?

regards,
hteles

Hi dear fellows.

Still strugling with a way to disable File & folder Properties.

The most unwanted part is the one where you go to advanced permissions and you can see all the system users.

Any one have a idea how to disable that?

My kdegloblals related section

[KDE Action Restrictions][$i]
action/editfiletype=false
action/properties=false
action/openwith=false
action/openintab=false
action/iconview_preview=false
action/sharefile=false
action/sendURL=false
action/sendPage=false
action/devnew=false
#action/incIconSize=false
#action/decIconSize=false
action/executeshellcommand=false
action/show_dot=false
action/show hidden=false
action/showhidden=false
action/show_hidden=false
action/toggleSpeedbar=false
action/separate dirs=false
action/show_dot=false
action/preview=false

@Frank: The KAuthorized class controls Kiosk interaction I believe.

Hi,

The problem still Exists in Kde 4.9.0

Is there any other way to to do the same with permissions?
I was thinking in something like remove permissions to a KDE lib! i can't seem to find any lib that is linked to KDE when you open the Permissions Properties of any file or folder,

Thanks,
helmer

Sorry for not replying earlier. Since I was asked to take over Dolphin's maintainership, I was constantly struggling with my email inbox which is always full and a large amount of bug reports and therefore neglected other communication channels. I'll try to check the forum more often in the future.

bcooksley wrote:@Frank: The KAuthorized class controls Kiosk interaction I believe.

Thanks for the hint.

hteles wrote:The problem still Exists in Kde 4.9.0

Well, yes, bugs unfortunately don't resolve themselves

I would suggest to create a bug report at bugs.kde.org. We cannot keep track of the bugs if they are not all in a single data base. I hope that someone will eventually look into it, but I cannot make any promises.

freininghaus wrote:Sorry for not replying earlier. Since I was asked to take over Dolphin's maintainership, I was constantly struggling with my email inbox which is always full and a large amount of bug reports and therefore neglected other communication channels. I'll try to check the forum more often in the future.

bcooksley wrote:@Frank: The KAuthorized class controls Kiosk interaction I believe.

Thanks for the hint.

hteles wrote:The problem still Exists in Kde 4.9.0

Well, yes, bugs unfortunately don't resolve themselves

I would suggest to create a bug report at bugs.kde.org. We cannot keep track of the bugs if they are not all in a single data base. I hope that someone will eventually look into it, but I cannot make any promises.

Hello,

i've been working in implementing a fully kiosked kde4 to replace our legacy kde3 enviroment.
Since then i've managed to circunvent so many problems by running around with diferent applications that i probably have forgotten to submit that bug report, but even then i'm not quite sure.

I've managed to skip that problem by using dolphin instead of konqueror, dolphin doesn't show file properties to the level of showing all of the users running on that machine, but unfortenly has other problems that i think that i've submited already

I'm submitting a bug right now.

regards,
Helmer

Thanks for submitting the bug report! If nobody comments on it soon, I'll ask on kde-core-devel for advice about the best way to make it work. I've looked at the KAuthorized docs because Ben mentioned it, but I couldn't find anything helpful there (looks more like a way to circumvent Kiosk restrictions that would prevent an app from working properly). If the information in

http://techbase.kde.org/Development/Tut ... p_Profiles

is accurate, it looks like we have to check if an option is immutable in all places where options are changed. Unfortunately, it looks like this would be a lot of work

I guess the problem right now is that changing the option in the config files is prevented by the Kiosk framework, but Dolphin does not check if setting the option has failed or not and changes the internal state of the application in every case.

freininghaus wrote:Thanks for submitting the bug report! If nobody comments on it soon, I'll ask on kde-core-devel for advice about the best way to make it work. I've looked at the KAuthorized docs because Ben mentioned it, but I couldn't find anything helpful there (looks more like a way to circumvent Kiosk restrictions that would prevent an app from working properly). If the information in

http://techbase.kde.org/Development/Tut ... p_Profiles

is accurate, it looks like we have to check if an option is immutable in all places where options are changed. Unfortunately, it looks like this would be a lot of work

I guess the problem right now is that changing the option in the config files is prevented by the Kiosk framework, but Dolphin does not check if setting the option has failed or not and changes the internal state of the application in every case.

Hi,

thanks for the input, really apreciated

I have a few more bugs to submit, but i'm working alone against the time to finalize this project and it has been a lot of effort.
Later i will update userbase with some of my findings.

Still a lot to resolve yet in kiosking kde4.
Problems i'm facing now have to do with the fact when people try to run kde4 in a technology like nomachine NX, x2go and others where shapes, screen dimensions and other stuff changes things get pretty bad.

Lots of problems with panel resizing, screen refreshing when you create or delete a folder shared via network from the customer remote location, problems when resuming a suspended session and later restoring with a different resolution, without killing plasma you will get only part of the screen with kde and the rest with a black border of the root window.

As i said before in other post, kde relies in full path, so you have problems when you want to use [KDE URL Restrictions] with ark, dolphin and kde kickoff saying that can not open file:/. or ark bailing out because wants to show full path inside the left window where you select the extracted folder.

regards,
Helmer

Kde someday will achieve world domination

@Helmer: With regards to remote file notification (assuming you are using NFS) you may wish to look into FAM and Gamin.

bcooksley wrote:@Helmer: With regards to remote file notification (assuming you are using NFS) you may wish to look into FAM and Gamin.

Hi bcooksley

i was talking about sshfs & fuse, part of x2go http://wiki.x2go.org/ to manage remote printiing and folder share to a Unix Enviroment.
Whenever a folder tunnel are established it creates a symbolink link in users running desktop - what i saw before is that you have to refresh screen to see the folder/shortcut appear or disappear of the screen whenever it changes state.

i'm seeing some improvements in kde 4.9.2 in regards of resolution changes, but the panel somehow isn't working perfectly. My target now is kubuntu 12.10 which is almost ready because of kde 4.9.2 better state.

so, now i have to have a lots of hacks for some kinds of limitations that i will put here, maybe will be usefull to someone.

My startkde pre-script

Code: Select all

#!/bin/bash

#resizepanel cos whenever a user uses a different PC/resolution panel will not adjust and also resolution
/usr/local/bin/fn_resizepanel.sh

#when a user suspend/resume a session the remote icon will not be accurate if the sshfs folder is not mounted, the folder wlll stay on the last state
/usr/local/bin/fn_getmounts.sh &

#call the real Kde start script
/usr/bin/startkde


My resizepanel and screen- called before new session start and after a session resuming in a sense of nxagent resuming.
this is where the biggest problem are, cos if you connect first at 1600x1200 and later resume at 1024x768 or the other way around, kde plasma will be too big or too small, smaller than a full screen nxagent root window

Code: Select all

#!/bin/bash

ResizePanel()
{

if [ -e  ~/.kde/share/config/plasma-desktop-appletsrc  ]; then

SESSIONDP=`x2golistdesktops |cut -d : -f 2`
export DISPLAY=:${SESSIONDP}

WSIZE=`xdpyinfo |grep -i dimensions|awk '{print $2}'|cut -d x -f 1`
HSIZE=`xdpyinfo |grep -i dimensions|awk '{print $2}'|cut -d x -f 2`

kwriteconfig --file ~/.kde/share/config/plasma-desktop-appletsrc --group Containments --group 1 --key geometry 0,0,${WSIZE},${HSIZE}
kwriteconfig --file ~/.kde/share/config/plasma-desktop-appletsrc --group Containments --group 3  --key geometry 0,-51,${WSIZE},45
kwriteconfig --file ~/.kde/share/config/plasma-desktop-appletsrc --group Containments --group 3 --group Configuration --key minimumSize  ${WSIZE},45
kwriteconfig --file ~/.kde/share/config/plasma-desktop-appletsrc --group Containments --group 3 --group Configuration --key maximumSize  ${WSIZE},45
kwriteconfig --file ~/.kde/share/config/plasma-desktop-appletsrc --group Containments --group 1 --group Wallpaper --group image --key wallpaperposition 2

fi

}

ResizePanel


So, this is whenever we start a new empty session.
In case in the end of the day we don't logout but we do x2go suspend and at home we got ourselves a smaller monitor?

this is one script that is runned after session resume

Code: Select all

#!/bin/bash

resize_screen()
{

SESSIONDP=`x2golistdesktops |cut -d : -f 2`
export DISPLAY=:${SESSIONDP}

kquitapp plasma-desktop

sleep 2

/usr/local/bin/fn_resizepanel.sh

sleep 1

plasma-desktop
spikedlg --passivepopup 'Por favor aguarde, a restaurar a sua sessão ... ' 10

}

resize_screen
/usr/local/bin/fn_getmounts.sh

exit 0



So, as you see, i have to kill plasma, write a new value for panel, display geometry. After that the session is adjusted accordingly to the new monitor resolution. I think that with kde 4.9.2 ( still testing) you can do xrandr -s newwithxnewheight and the desktop will adjust itself but i think that the panel will stay the same size as it was before.

There are other scripts involved, because of the problem of the folder in Desktop stay in last state after resuming if you don't force a screen refresh, but i guess that those aren't that important.

regards,
Helmer