From kde-usability  Fri Aug 15 18:24:01 2003
From: Simon Edwards <simon () simonzone ! com> (by way of Simon Edwards
Date: Fri, 15 Aug 2003 18:24:01 +0000
To: kde-usability
Subject: Re: FIXED: Secure Screen Locking
X-MARC-Message: https://marc.info/?l=kde-usability&m=106097227204146

[I just wrote a page of text and Kmail crashed. no dead.letter. grrr]

On Friday 15 August 2003 01:03, Aaron J. Seigo wrote:
> On Thursday 14 August 2003 04:11, Eron Lloyd wrote:
> > Oops...end of the day mistake. Here is the final file instead, fixing item
> > # 3.
> 
> interesting idea... i'd suggest that the failed attempts should not be shown 
> on-screen by default (in case you had simply mistyped your password by one 
> keystroke; don't want that shown).. perhaps a "Show Failed Attempts" button 
> that expands to show the table of failed attempts...

Guys, I really thing that this is something that should be handled by the 
root. PAM will already write failed login attempts to the system log.

The core problem here is that linux already has very good logging in place, 
but AFAIK KDE and the other DEs don't have a mechanisism in place notifying 
the current interactive user (i.e. the person behind the mouse) about all of 
the interesting info that is placed in the system log.

Examples of events that should be reported and perhaps acted upon in the 
current GUI session:

* Network connection up/down
* Printer up/down
* Digital camera connected and available for use.
* Disk space down to 5%.
* etc.

That's not even counting any stuff that the admininstator might want to know 
about (such as failed logins), or other applications.

Now, one of my pet projects is a realtime firewall monitor called Watchdog. 
It's alpha quality code, and I haven't released the current (rewritten) 
version of it. But it basically does the kind of things that I described 
above, except that right now it only handles packet hit messages in the 
system log. It has two parts, a daemon/server part that runs constantly (and 
can also automatically carry out actions such as DNS lookups etc) and a KDE 
GUI part that communicates to the daemon, receives event notifications and 
acts on them (adding them to the event window etc). What I'm getting at is 
that, maybe what I have here is a good base to build a general purpose 
notification mechanisism. The base code exists and works, and was designed 
well enough that it doesn't care what kind of messages it moves.

Does this sound interesting to anyone?

I'm just throwing this idea into the ring right now.

cheers,

-- 
Simon Edwards             | Guarddog Firewall
simon@simonzone.com       | http://www.simonzone.com/software/
Nijmegen, The Netherlands | "ZooTV? You made the right choice."


_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-usability