I submitted a patch to bug
report 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