Quality checks (again)

[Waldo Bastian]

On Monday 20 March 2006 08:04, Thiago Macieira wrote:
> > 7. KIOSK aware (merge with 6?)
> >The settings of your applications can be locked down with the help of
> >KIOSK methods ([$i] in the config file). Means that if the global
> >config file (or in a config file from a profile matching the user) has
> >an entry with [$i] after it, the setting cannot be changed by the user,
> >and if he/she changes in the local config file, it will be ignored.
> >Valid for applications.
>
> Again, valid for libraries too. But I don't think it should be merged:
> making settings documented and using KXConfig and preparing a KIOSK mode
> are two completely different use-cases. The configuration locking is done
> at the KConfig-level or deeper (backend). There's nothing the application
> author needs to do to enable it.

The application author may need to add some custom restrictions to his 
application. E.g. if the application provides a way to run arbitrary 
commands, the application may want to check the shell_access authorisation 
before allowing the user to do that.

In general, even though KConfig enforces KIOSK restrictions at the config file 
level, an application may want to make sure that it properly handles some 
common restrictions in the UI as well. Also the effectiveness of KIOSK 
restrictions is influenced by how configuration files are used.

> Besides, I'm not sure if this is a point at all. Some applications are not
> supposed to be used in KIOSK-mode at all. A very simple example
> is "konsole". If you allow a user to run it, there's nothing stopping him
> from loading other programs or doing operations that you've forbidden in
> other places (such as file erasing in Konqueror).

That's a bad example. Konsole can be used to run legacy text-based 
applications. Even though you may want a user to be able to run such 
application, that doesn't mean you want him to be able to start an arbitrary 
comand line shell. 

> I think this could be an "extra item": applications that do intend to be
> used in a KIOSK environment would get a "KIOSK-certified"
> seal/award/stamp/whatever and would document what can and cannot be
> locked down. This also means the authors accept bugs for failing to
> comply to the KIOSK settings.

That would work.

Cheers,
Waldo
-- 
Linux Client Architect - Channel Platform Solutions Group - Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060320/0a0f45ef/attachment.sig>