3 Dec
2011
3 Dec
'11
2:05 a.m.
On Fri, Dec 2, 2011 at 5:46 PM, Darrell Anderson <humanreadable(a)yahoo.com>wrote;wrote:
They should decide when it's a feature that does not cause problems for
anyone. I think that saving it in memory can be potentially exploited and
is something that shouldn't be done. If there's one thing Linux does well
is security (at least better...) and that is mostly due to asking for root
user credentials when performing system related tasks. People usually like
to use Windows with an admin account but, since they don't know any better,
they end up with malware riddled systems after a short while and accept
that as the norm, where if they would just keep it as a user account
Windows systems are reasonably secured and malware free for a long time.
From my experience, performing admin tasks is so sporadic it doesn't
deserve a feature like this. A power user has the better alternative to
just login the root account and close it when it's done. I actually don't
think kdm should be stopping you from logging in as root by default, since
it is rather useful sometimes. It just should hide the root account from
the user's list.
IMHO, if someone needs this feature, this should be explicitly enabled
somewhere instead of exposing it to unknowing users which will just ignore
any warning that's put up.
Best regards,
Tiago
Best regards,
Tiago
IMHO, the save
password dialog was always confusing
(didn't say for how long it would save) and it a pretty
big security liability. For me it is better to keep asking
the password for everything that is admin related - no
exceptions.
A "What's This?" tooltip popup could be added to the widget explaining the
password is good only for that session and only for the period secified in
defaults.h.
Or that same text could be added just below the check box widget.
Or both. :)
Proposed text:
Passwords are stored only in memory, only for each session, only for each
app, and only for $PERIOD minutes.
The point again is some people want this feature and some don't. The only
solution is to provide a mechanism to satisfy both crowds. Upstream
developers should not decide --- let users decide. :)
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:
http://trinity-devel.pearsoncomputing.net/
Please remember not to top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting