On Wed, Nov 30, 2011 at 7:10 AM, Darrell Anderson <humanreadable@yahoo.com> wrote:

> > I submitted a patch to bug
> report 388
> > (http://bugs.pearsoncomputing.net/show_bug.cgi?id=388).
> The patch restores
> > the visibility of the kdesu "Keep password" check box.
> In TDE, the check
> > box is hard-coded invisible rather than being a
> function of the kdesu -t
> > parameter as in 3.5.10.
> >
> > The patch (kdebase/kdesu/kdesu/kdesu.cpp):
> >
> > ================================================
> > // Try to exec the command with
> kdesud.
> > bool keep = !args->isSet("n")
> && have_daemon;
> > - bool terminal = true;
> > + bool terminal = args->isSet("t");
> > bool new_dcop =
> args->isSet("newdcop");
> > bool withIgnoreButton =
> args->isSet("ignorebutton");
> > ================================================
> >
> > Although I suspect many will welcome the patch, there
> likely will be just
> > as many who will fear being eaten in the dark by grues
> if this check box
> > is visible.
> >
> > I dislike the idea of those who want this check box
> visible to have to
> > always patch the TDE sources in their build scripts.
> >
> > Is there a way to test who wants this check box
> visible and those who
> > don't so no build-time patching is required and
> everybody is happy?
> >
> > I think the 'buntu family of distros don't use kdesu
> and instead use
> > kdesudo. Perhaps this patch does not affect those
> distros. If that is the
> > case then the discussion falls on everybody else.
> >
> > Ideas?
>

> The problem is that AFAIK there is no way to *unset* the
> password once it
> is stored. Possibly a better idea would be to file an
> enhancement bug
> report for a kcontrol module to reset the stored password,
> and then block
> 388 on that new bug report. Also we should add a
> brief dialog when the
> password is stored for the first time letting the user know
> where to go to
> unset the stored password.

Perhaps the code set has changed in TDE from 3.5.10. If I understand correctly kdesu in 3.5.10 worked like this:

* The password is not recorded in any config file anywhere. The password is maintained in memory.

* The password is good only for that session. Exiting TDE kills all kdesu hooks. If running with a graphical login that would be exiting TDE to the login manager. If running X from the command line that would be exiting X back to the command line. Logging out at the command line is not necessary --- only exiting the TDE session.

* If the check box is not enabled, the password is forgotten immediately. This is easily tested by closing the app and immediately running kdesu to run the same app. The password is again required.

* If the check box is enabled, the password is remembered only for the period set in $PREFIX/include/kdesu/defaults.h and ONLY for that app. I think the default is 2 hours. This is testable by waiting for the default time out period and then again launching kdesu for that app. A password is again required.

* If kdesu is launched for a different app, then repeat the previous steps. Passwords stored in memory for one app do not grant access to other apps.

Is the check box a potential security risk? That kind of question always opens the proverbial can of worms because the only way to start protecting a computer is to use in a locked room with no services running at all. :) Nonetheless, the time out period does pose a potential risk. Even if an admin closes a kdesu app, another person could restart the app if the timeout period has not expired. A safe policy is to not enable the check box in those environments or to use the TDE screen lockdown. Some people might then argue to just eliminate the check box, but not everybody works in that environment. The check box should be available to those who want the feature. For example, I work at home and have no cats to walk on my keyboard. :)

The administrator's section of KControl would be a good location to configure whether to show the check box. From the command line or konsole, running kdesu -n will open the dialog box without the check box. Disabling the check box through KControl would have the effect of setting the kdesu default to use the -n parameter. The setting could be saved in a kdesurc config file in /etc/trinity. Traditionally only admins have change permissions to /etc.

Perhaps there could be a default kdesurc in /usr/share/config, but the code looks in $SYSCONFDIR too for an admin system setting override.

A KControl portal keeps both sides happy. :)

kdesu does maintain a user's kdesurc file. If the user enables the check box, then the next time kdesu is run the check box is automatically enabled. Disable the check box and the next time kdesu is run the check box is empty.

Darrell

---------------------------------------------------------------------
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net
For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net
Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/
Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting