still trying to lock xfce...

[Brian J. Tarricone]

(moving to xfce4-dev)

Jasper Huijsmans wrote:

>On Tue, Mar 16, 2004 at 05:51:32AM -0500, Brian J. Tarricone wrote:
>  
>
>>the only "foolproof" method i can think 
>>of to lock down the environment is to check for a file, say 
>>$sysconfdir/xfce4/xfce_disable_user_config, and, if present, lock down 
>>the DE. (i'm sure there are other ways, but this seems easiest.) with 
>>this method, only users with write access to $sysconfdir (usually /etc) 
>>can change the system's lockdown state. even better would be to have 
>>said file contain a list of users for which the system is locked down, 
>>or, conversely, a list of users that are exempt from the lockdown.
>>
>>just an idle thought, dunno if anyone feels like messing with this...
>>    
>>
>
>I hadn't thought about the different users before. Another thing is
>perhaps to make it a little more configurable than all-or-nothing. I can
>imageine allowing a user to change the theme, but not the panel
>contents.
>
that's a cool idea (which of course requires even more time to design 
and implement).  i could see a totally locked down kiosk where all they 
want the user to do is run a web browser and absolutely nothing else.  
but then maybe it's a web/mail/word processing kiosk.  so maybe you'd 
like people to be able to save mail attachments to the desktop (yeah, 
it's coming...) so they can edit it with a text editor, or with gimp, or 
whatever.

for this to be done properly, something like this really needs a new 
interface in, say, libxfce4util.  the various DE apps need a way to 
register certain capabilities that may need to be locked down, and then 
later query the state of these capabilities, probably based on user 
and/or group.  this needs to be dynamic - it should be registered each 
time at app startup.  that way we don't end up with stale options if a 
later version removes a certain capability.  actually, this sounds like 
something suited for our new D-BUS daemon, since it essentially is a 
specific interface to a generic globally-accessible configuration store.

then we'd need a GUI configurator which essentially queries the API for 
a list of capabilities that can be locked down (there should probably be 
a way in the registration mechanism to group capabilities by app or by 
category) and display current settings and ways to modifty them.  what 
would also be nice is a set of pre-defined "profiles" that have some 
sane defaults for some commonly-used kiosk types (whatever they may be).

anyway, i can sit here and spew designs all day, but someone actually 
needs to be motivated enough to code it out.  right now that person 
isn't me ^_~.

    -brian