Whether "make pam_exec call a dbus method" qualifies for GSoC i don't know, but
with expose_authtok you can have the called exec read the login password from stdin - if
it's used for kwallet encryption, you can this way also unlock the wallet.
Otherwise you've to somewhere store the password/hash, pass it root access
only, read it with a pam_exec call, pass the output to a seteuid pam_exec call
for a process that waits for kwalletd to show up and does
org.kde.KWallet.pamOpen
The "tricky" part here is to make the user kwallet process store the password
(requires a suid helper which must not be tricked into writing into the wrong file)
Cheers,
Thomas
PS: no, i do not maintain nor even develop kwallet, just was pissed of being asked on
each login and after learning that once a wallet is open, there's no further protection,
I went for a generic "use cryptoloop" solution.
Took me ~5 minutes to create an encrypted loop device, mount it via pam_mount, move the
wallets there and (only "issue") trick kwallet into accepting a blank pasword.
On Mittwoch, 1. Mai 2013 09:48:24 CEST, Alexander Mezin wrote:
Hello.
I think that fixing this bug:
https://bugs.kde.org/show_bug.cgi?id=92845 could
be a good GSoC project.
It seems that KWallet can't be started from pam module (like gnome-keyring
do), but some "unlock helper" can be started with pam_exec.so. Password (or
hash) then can be passed to kwallet using local sockets. The only problem
is that I'm not sure how to do this secure enough (and what is "secure
enough")
If I'll also add configuration options (unlock some wallet automatically or
not, how long to keep it open, etc.), I think this will be enough for GSoC
project.
I didn't find any kwallet-related mailing list, so I'm posting here.
Are there anyone interested in this project?
Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
unsubscribe <<
Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
