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
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-devel-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail:
trinity-devel-help(a)lists.pearsoncomputing.net
Read list messsages on the Web archive: