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

List:       kfm-devel
Subject:    Persistent password caching (.netrc and .kionetrc)
From:       Dawit Alemayehu <adawit () kde ! org>
Date:       2001-06-11 9:13:22
[Download RAW message or body]

Hi,

I just committed a class that parses ".netrc" file as well as ".kionetrc" if available.
The idea behind ".kionetrc" is exactly the same as the ".netrc" with few minor additions.  The
".kionetrc" format supports two additional keywords: "type" and "preset".  The type keyword
is supposed to appear before the "macdef" keyword and is intended for specifying the protocol
or type of resource for which automatic login information is being cached, thus, allowing us to
extend the same functionalities of the ".netrc" format to support all of the other protocols we
support.  Furthermore, the code is flexible enough to allow the storage of multiple "login" info
for a single "machine" allowing us to store different automatic login info for the same "machine"
keyword.  The "preset" keyword functions exactly like the "default" entry, but unlike the default
keyword it is intended to denote application specific passwords.  An example of this would be
the optional email login info you can set in kmail's config dialog.

In terms of security, for reading from the file we follow the same requirements set on the ".netrc"
file, which is basically that the file must exist and only have "rw" permission for the user.  We also
check to see if the current geteuid() matches the uid set on the file.  Also these file must be in
the right location of course.  That is ".netrc" must be in while ".kionetrc" must be under the "config"
directory in $KDEHOME...

Anyways, in the long run the idea is to unify password caching for all applications that need it.
For example, kmail can store any login info provided in the account area in ".kionetrc" using the
"preset" keyword and setting the type file.  This makes it easier to allow the user to manage his
(her) password from a single control panel config module (when it is designed!).  Also we can store
webbased login information and provide similar facilities as Mozilla and IE do in this regards with a
very small overhead.

Oh BTW, all of this of course is optional as with everything else and will be off by default
for the very obvious reasons...

What do you all think ? Comments, opinions, ideas ? Is it a good idea to provide a centralized
location for storing persistent passwords ?

Regards,
Dawit A.

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