[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KConfig question
From:       Martijn Klingens <martijn () martijn ! homeip ! net>
Date:       2001-10-31 8:59:09
[Download RAW message or body]

On Tue, 30 Oct 2001, Waldo Bastian wrote:
> Running as root is rather hairy. E.g. you get files saved and owned by root
> and then later programs fail when running as user because they can't make
> changes to these root-files any longer.
>
> There was an idea floating around for "desktop settings" published via
> X-window properties that would solve a great deal of the look&feel problem
> but that hasn't gone anywhere.

Hmmm... I'd say that the app running as root would write changes to root's
.kde dir. But the user's .kde is read before root's, so if root doesn't
have a .kde you automagically get the user's prefs. As far as I understand
your recent KConfig changes this is perfectly possible and even ensures
that the user settings are read only and not accidentally overwritten.

The problem is still that you import _all_ settings this way, including
e.g. mail filters and potentially even scripting settings. So as soon as
kdesu based code is accessible without knowing a root password it would be
an instant security hole. In its current form it is not a problem, since
one could also 'su -' with the same password, which far easier to mess up
the box.

With your new KConfig code is now finally possible to block KConfig
entries from cascading down the tree. This allows to have a setting in
$KDEDIR whether KDE is installed in single-user or multi-user mode. In
single-user mode it would then be possible to loosen some security
restrictions. Not a good idea regarding trojans though, this needs more
thought. Hmm...

Martijn

[prev in list] [next in list] [prev in thread] [next in thread]