[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: FIXED: Secure Screen Locking
From:       Eron Lloyd <elloyd () lancaster ! lib ! pa ! us>
Date:       2003-08-15 19:15:07
[Download RAW message or body]

Hello Simon,

On Friday August 15 2003 2:24 pm, Simon Edwards wrote:
> [I just wrote a page of text and Kmail crashed. no dead.letter. grrr]

Didn't KMail recover your message?

> 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.

Great ideas. This is way beyond my league of coding/OS knowledge, but 
something that probably would be a great project for KDE 3.3/4.0. However, 
one of my basic concerns is that because in a way KDE is "platform-neutral", 
any features like this should be abstracted from the actual OS, because what 
works in Linux might not work under Solaris or BSD. It would be quite simple 
to have kdesktop_lock pass a QObject on login to a dialog that warns of 
failed access attempts, much harder to interface to PAM, etc. through a new 
system notification layer. Perhaps you should present this idea to 
kde-core-devel?

Eron

-- 
Eron Lloyd
Technology Coordinator
Lancaster County Library
elloyd@lancaster.lib.pa.us
Phone: 717-239-2116
Fax: 717-394-3083

---
[This E-mail scanned for viruses by Declude Virus]

_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]