Version: (using KDE KDE 3.3.1) Installed from: Gentoo Packages OS: Linux It should be possible to use PAM with KWallet. This way I think a secure single-sign-on could be made possible by using the PAM module pam_ssh. You´d have to setup your /etc/pam.d/system-auth file to use pam_ssh as an alternative to pam_unix. Then you are able to login to your computer by entering the passphrase of your private key in ~/.ssh/. The thing that make single-sign-on possible is that pam_ssh automatically launches the ssh-agent tool (belongs to OpenSSH) so that you´ll never have to enter your private key´s passphrase again when it is needed for example by KWallet. I do not understand more about this topic than I´ve written down here, but I think it might satisfy the wish for a passwordless KWallet without of making it stupidly insecure.
*** This bug has been confirmed by popular vote. ***
Something similiar could also be done by storing the user's password in the wallet, and then have KDM silently login to the wallet (user clicks his user, and instead of account password types the wallet password) to get the linux password and log in with that.
Would be nice to integrate KDM and KWallet!
Just in case this gets implemented (and I really hope so...), I'd like to point out that it should be implemented in such a way as to be compatible with pam_mount. Currently I'm using an encrypted home partition that is mounted automatically at login by pam_mount (using the login password). Using information from the user's home could be problematic when it's not yet mounted. So, please consider this point. It would just be too cool to have single-sign-on for the system login, pam_mount and kwallet. Thanks for listening :-)
I'd like to have single-sign-on also working with the default login password. Please also keep in mind that not all people use kdm as their login manager (or no login manager at all! Runlevel 3, need I say more? ;-) ), so it should not depend on kdm or any graphical login procedure.
what would have to happen then? will kwallet become a frontend/gui for the 'wallet' cli app, being useable without qt , kde or anything, and wallet would be a base system / libs for ppl to store their many passwords, possibly with bindings for other languages to use it, hopefully with Mozilla, Gnome, Freedesktop.org and possibly other ppl cooperation, so that we can have a solution which is not kde specific, but which encompasses the whole desktop? Maybe it should be talked with other parties which may be interested in the subject. Maybe I am overly optimistic, but I think this would be the best thing possible to happen: a unified wallet system with single sign-on useable by any desktop environment, so that I can use any desktop without having to retype the passwords in mozilla, konqueror, or foo.
I'm investigating this for the community over at LinuxBiometrics.com. We have talked a bit about how to most effectively integrate biometrics and so I'm investigating. We already have work building a PAM bridge and so Kwallet's attachment to PAM would significantly ease the efforts that would need to be made. Just wanted to share that we see this as being a beneficial direction for our needs also. :-)
*** Bug 102465 has been marked as a duplicate of this bug. ***
Wouldn't be a kwallet pam module possible? It would start kwallet as soon as one logs in. This way it works also for other types of logins (NX, console, xdm,..) and doens't relay on ssh. Of course an auto login to kwallet isn't much safer than a kwallet without password, but it adds an extra little bit of security (e.g. secure as long as you don't log in) at no cost for the user. So I think it should be possible.
If I understand the following page correctly something similar already exists for Gnome: http://www.flyn.org/projects/pam_keyring/index.html
In reply to comment #10 (Gilles Schintgen): > If I understand the following page correctly something similar already exists for Gnome: > http://www.flyn.org/projects/pam_keyring/index.html This looks exactly what we need for KWallet.
> http://www.flyn.org/projects/pam_keyring/index.html And it's abandoned, so we can take it over any time :-)
Gnome hat it and Mac OS x has it too: http://developer.apple.com/documentation/Security/Conceptual/keychainServConcepts/02concepts/chapter_2_section_1.html So we need it, also! ;-) The first step we need, is a seperation of the daemon and the gui. Like gnome does it (gnome keychain daemon/manager). Otherwise the pam module can't start the daemon because of the gui dependance. Should this be an own feature request?
On Sunday 18 September 2005 05:02, Roland Schulz wrote: > Gnome hat it and Mac OS x has it too: > http://developer.apple.com/documentation/Security/Conceptual/keychainServCo >ncepts/02concepts/chapter_2_section_1.html > > So we need it, also! ;-) > > The first step we need, is a seperation of the daemon and the gui. Like > gnome does it (gnome keychain daemon/manager). Otherwise the pam module > can't start the daemon because of the gui dependance. Should this be an own > feature request? Right now the whole thing is very dependent on Qt and actually DCOP. Once KDE4 development really starts (ie: technology changes in kdelibs begin), this can be considered.
Personally, I think teh Best Way Possible® it to get in touch with Freedesktop.org and Gnome people too, and draft a standard way to do it, place under teh Freedesktop.org umbrella. You know, avoiding the NIHS (Not-Invented Here Syndrome), and doing something which can benefit all, instead of something KDE-centric. AFAIK tehre are already 'standards', at least in draft form, for things like DE-agnostic themes, clipboard, and so on. This could be one more thing.
On Sunday 18 September 2005 11:48, Tiago Freire wrote: > ------- Personally, I think teh Best Way Possible® it to get in touch with > Freedesktop.org and Gnome people too, and draft a standard way to do it, > place under teh Freedesktop.org umbrella. You know, avoiding the NIHS > (Not-Invented Here Syndrome), and doing something which can benefit all, > instead of something KDE-centric. If there was interest on that side, why didn't they come to us and say they wanted to co-operate too? KWallet is quite old and I've never seen or heard of something similar on Linux or Gnome. That being said, the file format is open and there is a chance to extract the daemon outside of KDE startup now that dbus is a likely candidate for KDE4. I don't have any interest in redesigning and reimplementing all of KWallet though. It works, and there are many other things that need to be done in KDE4.
Am Montag, 19. September 2005 00:30 schrieb George Staikos: > If there was interest on that side, why didn't they come to us and say > they wanted to co-operate too? KWallet is quite old and I've never seen or > heard of something similar on Linux or Gnome. Right you are. It's about time that Gnome incorporates some precedent set by KDE.
On Monday 19 September 2005 10:16, Leo Savernik wrote: > Am Montag, 19. September 2005 00:30 schrieb George Staikos: > > If there was interest on that side, why didn't they come to us and say > > they wanted to co-operate too? KWallet is quite old and I've never seen > > or heard of something similar on Linux or Gnome. > > Right you are. It's about time that Gnome incorporates some precedent set > by KDE. That's not true either. They have and do (see freedesktop). I just don't buy this argument that KWallet was done at the preclusion of Gnome. It preceded any other similar project that I could find at the time.
There are several standards, in draft form or otherwise, being developed or promoted for adoption on freedesktop.org. The 'Single' bit of 'Single Sign-On' only holds completely true if it works on every application. If you only use KDE apps, fine, but I find thinking like this a bit selfish (and I am not implying it is your thinking, just stating my belief). Ithink it is really worth pushing forward the 'Single' part of this idea, and have filed a project-request-bug at freedesktop.org. https://bugs.freedesktop.org/show_bug.cgi?id=4513
Uh. It would be awesome to use pam_usb (http://www.pamusb.com) with KWallet, too.
*** Bug 114662 has been marked as a duplicate of this bug. ***
Absolutely fantastic idea. I vote with 20 points!
it is really required to have this done using PAM ? I'm don't know. But the basic idea of having the kwallet automatically open upon login is strongly wished and I really wish to see this feature in the next release of KDE. thanks
Actualy I think it would be possible using Kwallet integration in KDM. So that the account password is stored inside the wallet, and at logon time you just enter the password for the wallet. What do you think?
Hi Andrei, This would be excellent, yes! Do you think it is possible technically? Thanks!
> Actualy I think it would be possible using Kwallet integration in > KDM. So that the account password is stored inside the wallet, and at logon > time you just enter the password for the wallet. What do you think? No, the account password should always be the one stored in /etc/shadow. Everything else would be incoherent. In my opinion, having the login password depend on how you login (login, ssh, kdm) would be a terrible idea. The password entered into kdm can already be reused by other PAM modules, such as pam_mount. kwallet could "simply" integrate with PAM and obtain the password in the same way. The kwallet password would then be your login password. If the login password is changed, decrypting of the wallet will fail and kwallet would inform the user about it and ask for the old password in order to reencrypt the wallet with the new password. What do you think about this idea?
With my apologies, Gilles, I think I disagree with your judgment on authentication sources: the whole point of pluggable authentication modules (P.A.M. :)) is precisely to let you authenticate yourself from different possible sources. I am not sure what invalidates KWallet as one such source, but I might be overlooking something, of course. However, would it be possible to simply encrypt the KWallet password using the user's login password? This way, when the user logs in, he uses his regular login password; that password is also used to unlock his KWallet password, and KWallet is then loaded as usual. Would PAM allow for such a behavior? This way, it would respect Gilles' misgivings about the previously suggested behavior, while still allowing for KWallet to be opened automatically at login time, and still allowing for different login and KWallet passwords. What do you think?
> With my apologies, Gilles [...] I'm sorry if my response sounded a bit harsh, it really wasn't intended that way. > However, would it be possible to simply encrypt the KWallet password using > the user's login password? This way, when the user logs in, he uses his > regular login password; that password is also used to unlock his KWallet > password, and KWallet is then loaded as usual. There's a second reason I don't like this behaviour: I'm using an encrypted home partition which is automatically decrypted by pam_mount using my login password. Since the KWallet data is stored inside this partition I don't see how this scheme could be implemented without breaking this kind of setup. This same problem also arises for people using pam_mount to mount a remote home directory. Unfortunately kdm can't rely on (or at least it shouldn't) the availability of the KWallet data before the user is authenticated by PAM. Except, of course, if the KWallet were to be stored outside the user's home directory which, I think, would be a bad idea. Kind regards, Gilles
> This way, when the user logs in, he uses > his regular login password; that password is also used to unlock his > KWallet password, and KWallet is then loaded as usual. I'm not sure about this. This creates a what looks like a bad scenario where kwallet-stored passwords are available upon request once a user is logged in. Well, what if I'm a bad guy and somehow get access to your desktop? I think my first stop is kwallet. It's open right? Personally, it doesn't bother me that kwallet asks for a password upon opening after I'm into my desktop. Below the gui level, PAM and kwallet must remain separate. The kwallet gui needs to make it appear something like a single wallet though.
> Well, what if I'm a bad guy and somehow get access to your desktop? Then I should have locked my desktop. My second act, as a bad guy, is to change your desktop background to a picture of Tom Welling with his shirt off. Very few people around my office forget to lock their desktop anymore.
Gilles, Please note that in my last proposal, to my knowledge, KWallet could be opened only after everything else has been unlocked, i.e. after the login process has begun and the home partition has been mounted, in the same way that your home partition is only mounted after your authentication credentials have been validated. So your setup would not be prevented from working. If I'm not wrong in this and what I'm suggesting is indeed possible, would the proposal satisfy you? Michael, Would this be different from the usual way KWallet works? Once your KWallet is opened, some Bad Guy sneaking his way to your desk can access its passwords as well. The only difference would be that at login time -- when you're known to be at your desk -- the KWallet would be loaded as usual, simply without asking for its own password. But you raise a good point, and the unlocking of KWallet at login time should be an option. Perhaps it is worth pointing out that, as things currently stand, many users choose to use no password at all for their KWallet -- incidentally storing all its passwords in clear text -- so as to avoid the annoyance of unlocking it manually at login time. Our proposal ideas here would be a significant step up from that behavior in terms of security. With kind regards, -- S.
> Please note that in my last proposal, to my knowledge, KWallet could be > opened only after everything else has been unlocked, i.e. after the login > process has begun and the home partition has been mounted Now I see that I've misread your last proposal: > However, would it be possible to simply encrypt the KWallet password using > the user's login password? This way, when the user logs in, he uses his > regular login password; that password is also used to unlock his KWallet > password, and KWallet is then loaded as usual. I thought it was the same proposal as before, except that now the two passwords are the same. In other words I interpreted "he uses his regular login password" as "he types the same password as always but it's first used to open the wallet in order to retrieve the account password". > would the proposal satisfy you? Yes, it would be fine (for me). The only difference to my proposal is that KWallet doesn't get the password through PAM, but directly from kdm. My proposal would also work with console logins (but I'm not sure this would be desirable) and with xdm and gdm. Since I'm mostly using kdm, I'm not going to insist on this. (And I don't know how difficult it would be to properly implement the PAM integration.) In the long term I'd prefer a desktop-independent approach, as already pointed out in comment #19. Regards, Gilles
I am not convinced of the PAM thing in this case. I beleive comment #27 is saying about same thing as me and I totally agree with sundance. lets not change to much and just use the password from kdm to open the wallet. actually, if I understand the PAM idea, It's totally different and would serve a totally different purpose. I think people are fighting for a different egg.
> No, the account password should always be the one stored in /etc/shadow. > Everything else would be incoherent. In my opinion, having the login password > depend on how you login (login, ssh, kdm) would be a terrible idea. Well, of course the password from /etc/shadow (or NIS, whatever is used by the system) will be used to actualy authenticate the user, I was just suggesting that instead of typing the password in KDM it could be taken from the wallet. > The password entered into kdm can already be reused by other PAM modules, > such as pam_mount. kwallet could "simply" integrate with PAM and obtain the > password in the same way. Not everybody uses PAM, it is possible to configure a system to autenticate directly from /etc/shadow. > The kwallet password would then be your login password. If the login password > is changed, decrypting of the wallet will fail and kwallet would inform the > user about it and ask for the old password in order to reencrypt the wallet > with the new password. Probably not everybody likes to have the same password for the account and wallet (the account password could get compromised easier then the wallet since it might also be used remotely). > There's a second reason I don't like this behaviour: I'm using an encrypted > home partition which is automatically decrypted by pam_mount using my login > password. Since the KWallet data is stored inside this partition I don't see > how this scheme could be implemented without breaking this kind of setup. With this you are right, I didn't consider this kind of setup. But I suppose you could just encrypt a subdirectory with your personal stuff, not the entire home.
> There's a second reason I don't like this behaviour: I'm using an encrypted > home partition which is automatically decrypted by pam_mount using my login > password. Since the KWallet data is stored inside this partition I don't see > how this scheme could be implemented without breaking this kind of setup. Perhaps there could be a backup/failsafe option to keep the old way of doing things for setups like this. In any case - if you have an encrypted /home, surely you don't actually need to encrypt the kwallet file (although admittedly you would need to if /home was network mounted and needed your account password)
why not have a crypted loop device containing a file with passwords stored in it (no need to change current KWallet config file layout)? This way, you could either mount this device at login, with pam_mount or mount it every time KWallet is used (depending on user settings). This should of course be done transparently to the user. The KWallet password would then be the same as the user password, but is this a problem ? If it is, the filesystem could be crypted with a different password, disabling the auto mount option. The only drawback I see to this approach is on systems different from linux ...
addition to #10, #11, #12: PAM_KEYRING for GNOME is not dead any more: http://www.hekanetworks.com/index.php/publisher/articleview/frmArticleID/25/staticId/31/ Personally, I'd like to see a modular, pluggable (multiplatform) solution using pam. Currently I'm using pam_ssh, keychain etc. for firing up gpg and ssh agents for my entire KDE session, which saves me a lot of "enter passphrase here"/"enter passphrase there" and works like a charm, I'm using fish:// URLs very often. That is, as long as I don't change my password/passphrases too often... It would be cool to have a wallet/keyring opened by some pam_module, and see (at least all FOSS )browsers, IMs, VoIPs etc use it seamlessly. If that framework could perform password/passphrase change transactions, I'd feel like in heaven.
There are ssh-agent and gpg-agent. So bring up a third agent for wallets(kde), keyrings(gnome) and passwords(firefox). This third agent should use kwallet as gui and have a libpam_wallet for single-sign-on. Perhaps this agent could also start the other two (ssh and gpg) and provide them the passphrases.
*** Bug 143687 has been marked as a duplicate of this bug. ***
I'm currently using a laptop with openSUSE, KDE, and a fingerprint reader (via PAM). The behavior I have now is that from KDM, I swipe my finger to login. Then, KWallet immediately prompts me for a password, because KNetworkManager stores my wireless keys in KWallet and 99% of time I login (home, work) there's a secure wireless network there to connect to. So in total, I have to swipe my finger and then enter a password, which is bothersome. In this situation, I am required to open KWallet as soon as I login (on account of KNetworkManager), so it would not bother me if the wallet was automatically opened upon login. If a bad guy steals my laptop while I'm logged in, my wallet will almost surely be open as is. I guess I'm looking for the outcome to be one of these: * I swipe my finger once to log in, the wallet is automatically opened, and I don't have to take any additional action. * I swipe my finger once to log in, and then again to open the wallet, but at least no password entry is required. This may mean that KWallet uses the fingerprint reader via PAM to unlock the wallet, or it may mean that KNetworkManager stops using KWallet for storage and instead uses some other mechanism that in turn uses the fingerprint reader via PAM to access the wireless keys. I will note that I would be far less concerned about this if KNetworkManager did not use KWallet, but since I'm so reliant on secure wireless networks, I'm therefore reliant on KWallet.
RE: Comment #40 I have a similar issue on my machine; having to swipe my finger to get into KDE and then having to enter my password after. While I see the benefits of not having PAM integration in KWallet, I can also see the benefit to making it an *option* to use pam for authentication; at least then by default it can be configured to use what it uses noe.
Do those finger print sensors send some kind of password computed from the finger profile or just a yes/no? In the later case there is no way you could safe unlock the wallet with it, because without a password you can't unencrypt.
I don't know enough about the BioAPI and related stuff to say for sure, but I don't believe the fingerprint reader stores a password. I think it's just a yes/no (based on the fact that I don't remember needing to type a password for it to remember when I first saved the fingerprint profile). Perhaps Josiah Ritchie (Comment #7) could say more. However, the user account in question still *has* a password. I'm not sure whether there's some way to retrieve it if you've successfully authenticated some other way. Or maybe the fingerprint reader returns some data on the finger geometry or something that could be used as a "password" to unencrypt. Or, maybe the fingerprint reader can be coerced to save some data along with the fingerprint profile and return that to use as a decrypt key. Hopefully someone who knows more about the biometric plumbing will speak up. :)
The fingerprint scanners do not in fact store a password. Instead it store some information about the users fingerprint. The primary problem here seems to be the encryption of the passwords. I wonder if a system similar to how the LUKS cryptfs works. Essentially you can have multiple keys for an encrypted partition, which in turn decrypt the real key. Perhaps to get the pam side of it working the user would have to run a configuration program and effectively "train" KWallet to use the information provided by PAM. I am not an expert in any way with PAM, but I do know that it is very flexible. Regardless of how one would get the fingerprint scanner to work, if KWallet worked with PAM, then the biometrics would work as well as they are just a PAM module.
> Regardless of how one would get the fingerprint scanner to work, if KWallet > worked with PAM, then the biometrics would work as well as they are just a PAM > module. Not quite. If the biometrics pam module doesn't provide a password, Kwallet won't be able to encrypt.
I have a T60p ThinkPad with integrated fingerprint reader using libthinkfinger for authentication. For simplicity, I would like to use my fingerprints to open KWallet too, but I don't think this will ever be possible: If you want to encrypt someting, you need some kind of secret to feed the encryption algorithm. If you just swipe your finger, the only secret you can supply is your fingerprint. Fingerprints may be OK for authentication but not for encryption. In Germany for instance, every citizen has to deposit all their 10 fingerprints to get a new ID-Card by the end of this year, so fingerprints can't be considered a secret any longer. Even if the bioapi/libthinkfinger libraries would return some kind of password, it would be insecure because this password generator has to be deterministic. So everybody who knows your fingerprints could generate the password, too. The only way I see, to provide some kind of secret using fingerprints, is a series of fingerprint scans with the different fingers of your hand. The order of the fingers you use is the secret. But I don't think this could be seriously considered secure, because brute-force attacks would success within a second, unless you require the user to provide a series of 200 fingerscans or so ;) And I think it's even faster to type in your KWallet password than swiping your fingers 10 times or even just 4 times. So from my point of view, there are just two options: - Disable encryption in KWallet, so no password/fingerprint/whatever is required by the user (not even for authentication, because he is already authenticated), and hope that nobody can access your KWallet files. - Live with the fact, that KWallet requires a password to encrypt your stuff. - (Wait for the first open-source/open-design brain-computer interfaces ;))
I really like the idea of using PAM. At the moment I use pamusb and I still have to type in my password to open kwallet (which happens at every startup because of kopete connecting to the net). Sometimes it gets really annoying. It would be great to have some kind of single-sign-on-system which also integrates Mozilla or other open source software. Just an idea: why not using a public/private key infrastructure. The private key is stored somewhere in the users .kde directory with read only to the owner. If the user authenticates via PAM kwallet is allowed to use the private key. The user can still close the wallet requiring to authenticate again (no matter how), if he wants to open the wallet. Of course this does not really protect the wallet. But perhaps it would be possible that the user defines a passphrase, so he can choose if he wants to have comfort or security. Nevertheless the content would be encrypted in both cases.
There is a discussion about fingerprint integration in KDM right here: http://bugs.kde.org/show_bug.cgi?id=116682 which has some similar points. As mentioned there, now here to joerg / comment #46 : Everybody should decide for her/himself how secure her/his system should be - we probably can show a warning like "fingerprint login is insecure" :-). And it's "only" your two forefingers for the new passport and the same two fingers whichh they discuss for the ID - so you can use anotherone or a toe ;-). So PAM would be perfect for KWallet - for me with pam_thinkfinger .
if PAM is not the perfect backend for KWallet, why KWallet could not use multiple backends, the same way as Phonon uses multiple backends?
I think the option proposed in comment #47 is just fine: * let PAM and the Core-OS do what they are designed for: Authenticate the user & authorize file access (here access to the secret key which is read-only for the authenticated user) [to me this behaviour would be similar to that of using SSH-Keys for passwordless SSH-authentication] * kwallet can use this secret key to encrypt/decrypt it's data You could leave the option up to the user (in kwallets config) whether to use a secret key in the homedir or an "old-style" password. From my point of view (which is the view of a user, not the one of a KDE/KWallet developer) the changes to kwallet would be small. No pam integration is needed, because when kwallet starts the user is already authenticated. The only thing that needs to be done is reading the secret key file (after assuring correct permissions (400)), and using the secret stored in this file instead of the password provided by the user
It's not quite similar. In my opinion it's not useful to store an encrypted file and the key to decrypt it so close to each other. It seems like the security you gain by doing this is pretty close to not encrypting the file at all.
*** Bug 184537 has been marked as a duplicate of this bug. ***
I have an additional idea, which I've posted in the KDE Brainstorming forum. >Now when a program ask KWallet about credentials KWallet looks into it's >(proposed by me) database for this application. If the application is present, >KWallet checks if it's entitled to get the crential it's asking for, or else >KWallet asking me (graphicly) what I want to do: Give it access once, or >forever, not now, or not forever. If the application is not in the database >KWallet asks me if I would like to add it. (and then the other questions). >(Alternativly, only the application how put the credentials in KWallet can >fetch them from there) >In this way I don't have to write passwords all the time. KWallet still asks >for permission, I'm in control. Bringing up the KWallet app-database lets me >modify my previous decisions to allow or disallow apps. >This assumes two things which I really don't know anything about: > * KWallet have to have the means of making sure that an application really is >what it seems to be... it's really a developer thing, but since every antivirus >program in windows manage it (and the firewall to) I can't be that hard. > * A program run as a user can't fiddle with another programs memory or windows >or such. IF this would be possible the asking (rouge) app could take control >over KWallet's dialog asking me for permession.... Is it out of scope?
@Markus: This is actually already in. I mean not the pam stuff but the "ask if the application may access the wallet" thing. There's a caveat though: * kwalletd doesn't determine the application's identity but trusts the application on providing the name
*** Bug 197788 has been marked as a duplicate of this bug. ***
*** Bug 210726 has been marked as a duplicate of this bug. ***
There is a PAM module and a client program available at http://download.opensuse.org/repositories/home:/hgraeber:/KDE4/ However, it tries to call DBUS method "tryOpen" that does not exists in any kwalletd that I examined (current KDE 4.3 packages for openSUSE 11.2 and KDE trunk), so it is not usable directly. It could be made to work with the "pamOpen" dbus method added by Michael (http://websvn.kde.org/?view=revision&revision=1054213), though.
(In reply to comment #57) > There is a PAM module and a client program available at > http://download.opensuse.org/repositories/home:/hgraeber:/KDE4/ This is only a version I tried to test an unfinished port of the KDE3 version of pam_kwallet. > However, it tries to call DBUS method "tryOpen" that does not exists in any > kwalletd that I examined (current KDE 4.3 packages for openSUSE 11.2 and KDE > trunk) tryOpen is an extension of kwalletd's dcop interface made by SUSE for KDE3. I had packages for kdebase4 with a similar extension the kwalletd's DBUS interface. > so it is not usable directly. It could be made to work with the > "pamOpen" dbus method added by Michael > (http://websvn.kde.org/?view=revision&revision=1054213), though. Now with this extension of kwalletd's DBUS interface pamOpen should be used. For this the program kwalletclient has to be changed to compute the has of the password before opening the wallet using pamOpen. The pam module pam_kwallet isn't needed because a pam module named pam_exec.so exists, which can do it's job.
I would SO like to have a working pam/kwallet integration back. maybe the one thing from kde3 that I'm missing most in kde4 right now.
As there seems to be a lot of interest in getting this working, a little update from my side: I'm currently working on this, but unfortunately it didn't turn out as easy as I hoped it would be. Currently the main problem is that PAM needs to launch the D-Bus session bus as well as kwalletd for automatically opening the wallet which turned out to be harder than expected.
(In reply to comment #59) > I would SO like to have a working pam/kwallet integration back. > maybe the one thing from kde3 that I'm missing most in kde4 right now. Mathias, what are you talking about? This never existed in kde3. This wish has been open for 6 years, with thousands of votes, yet nothing has been done about it. What we got instead in these 6 years is a "semantic desktop".
(In reply to comment #60) > I'm currently working on this, but unfortunately it didn't turn out as easy as > I hoped it would be. Thank you very much for your effort Michael. Hope you could get it done. Thanks
(In reply to comment #60) Hi Michael! It's almost 6 months since you wrote you were working on this so would be so kind to tell us how are you getting on? Will it be finished on next KDE release? cheers, Wojtek
Great idea! Any news?
Unfortunately it won't ship with the next version of KDE. The main problem is that accessing KWallet at the same time you can access the password is quite hard. It requires a PAM module that can access the user's D-Bus session bus which is usually started after login only. Now, the good thing is I worked around this by implementing a PAM module to launch the bus as well as the module that gets the password and sends it to KWallet and it's already working (well, at least for me). Unfortunately D-Bus developers seem to disagree that what I did was such a good idea. So until things have cleared a bit I won't do a real release of the modules. If you're able to you can however get the modules from here: - http://code.confuego.org/index.php/p/pamdbuslaunch - http://websvn.kde.org/trunk/playground/base/pam_kwallet
Thank you very much for your work Michael! :) Hope to get a the solution integrated soon.
I think, not having kwallet opened with user login is a decrease in security in some cases. pam is running in a non-user-context while any login attempt in an already running user session runs in user context. As a result any password sniffing app must run in root context for the former one while for the second one user context is enough. (In case of attacking the "open kwallet"-process. Attacking kwallet directly is on par.) Secondly. Having to type in a password twice in the login process is godawful, at least bothersome. Many people will prefer to use an empty password for kwallet because of this. This results in a _major_ loss in security. Even if there is some pam integration for kwallet, every one who wants can still use different passwords for os login and kwallet. So at least pam integration won't touch any security concerns for "the real safety-conscious people" out there. ;-)
I wonder if it could be possible to make kwallet use ssh private key. There are already pam_ssh and ssh-agent in the most distributions. And this approach has no problems with D-Bus, because pam_ssh unlocks private key and ssh_agent keeps it until kwallet may want to access it.
Vayu <yu.valery+bugzilla@gmail.com> wrote > https://bugs.kde.org/show_bug.cgi?id=92845 > --- Comment #68 from Vayu <yu valery+bugzilla gmail com> 2010-07-25 > 02:24:14 --- I wonder if it could be possible to make kwallet use ssh > private key. There are already pam_ssh and ssh-agent in the most > distributions. An approach that sounds nice. But, does kwallet not still need to be made aware of PAM? I mean, if there is no PAM support at all in kwallet, nothing will work, no ssh_pam, not libpampoldi with openPGP card? Vice versa, once kwallet supports PAM, any PAM module would work with kwallet, right? Regards Malte
I'm not a developer, but one or two questions come to my mind when reading this bugreport: The Gnome-devs seem to fixed this problem a long time ago. You can use the so called Gnome Keyring, and it will be opened directly when you login to the computer. So it seems they are using som kind of pam-module to open the keyring during login. So at last it is possible at all. Wouldn't it be a good idea to talk to the Gnome devs and ask them how they did it, instead of reinventing the wheel again? Maybe it is possible to share some of the code, so it gets a little bit easier. Or maybe it would be posssible to create a complete new wallet-like thing together with the Gnome-devs, so there would be only one wallet used in Gnome and KDE, just with different GUI for both desktop - one GTK+ and one QT (maybe a plasmoid?). And then create a pam-module together then can be used by either GDM and KDM to open the wallet, no matter which desktop is used. Don't forget I'm not a developer. So it's a little bit hard to say for my if this is possible at all. At least it seems like a good idea. Maybe a disscussion at the next Akademy would be good, since it will take place together with GUADEC, so the perfect "get together" of KDE and Gnome developers. Regards, Ralf
As someone that uses Kerberos and LDAP a lot, having PAM integration with KWallet would be a huge win, especially if we could get a plasma widget that did kinit and tgt renewal requests. :)
This feature would be great.
It would be great to see any forthcoming on this. The current kwallet situation is absolutely terrible. Any of the above mentioned solutions would be a BIG improvement.
indeed. Currently i'm forced to set a empty password for kwallet when i'm installing linux for somebody, simply because of usability reasons. A more secure solution would really be appreciated.
This request has been here for 7 years already, it has thousands of votes, and yet it hasn't even been acknowledged by any developer, its status is still "NEW" after 7 YEARS! Every new KDE release comes with more bugs, 4.6.0 in particular was terrible and I simply lost my motivation to report bugs and wishes that go ignored for years, this is just a waste of time.
alancio, I don't know how you can say it's been ignored, Michael Leupold has been working on this as documented above and it's really quite rude to say otherwise. If Michael says it is harder than it looks, then it must be hard. Remember, we are all volunteers here giving up our free time to work on KDE and we just can't do everything. Something else to consider is that KDE and Gnome are currently working on a common standard for storing passwords called Secret Service which will be draining resources as well, and may well offer a common solution for the problem. Personally I find KDE 4.6 to be the least buggy KDE ever (yes, even including KDE3, I think nostalgia makes people forget the bugs we had there).
I have been hearing about a unified wallet between gnome and KDE, is this problem not being addressed because of a shift to a unified wallet?
It is really frustrating that such a badly needed feature hasn't even been started within 7 years, while dozens of completely useless features find their way to new KDE releases. Come on KDE team I'm shure you can do better and please at least update the status of this bug!
What is "badly needed" and what is "completely useless" is a matter of personal opinion.
Please stop asking questions like "Do you really need it? Absolutely sure???" This is only going to frustrate users. I'm offering 25,- Euro to the guy/team who just gets it working, plus I can do some coding on the Qt/KDE (kwallet) part. Unfortunately, I don't know anything about PAM authentication and don't have the time to work myself in. Looks like there is just nobody out there having enough knowledge about PAM, KDM and Kwallet at the same time. So I think this just needs some coordination and teamwork. Of course as an alternative we can collect some money to write it out as a project for a freelancer.
make that 2500€ and somebody *might* bite. just to give you an idea of what effort we are talking about.
Well, 99 people (offering 25,-Euro) to go... and perhaps some student picks it up earlier :)
I would pay 10€ more. ¿a good web to collect these award wills and try to make it real?
If you're serious I donate 10 euros too!!
will there be a written guarantee from the "KDE Management" or whatever else the organization that decides what goes in KDE $current+1 calls itself, to the effect that this feature doesn't get removed in the next version just after someone came up with the 2500€?
on planetkde a) lightDM was mentioned as a crossdesktop alternative to kdm. and b) there was (freedesktop?) work goin on to unify gnomes (that open wallet on login) and kde wallet system. I hole heartly agree that it's very welcome to open the wallet at login time, but one should check if kwallet+kdm or lightDM+freedesktop-wallet or something else is the way implement the feature. Achim
I'll give 10 Euros via Paypal if it gets fixed. The time saving would be enormous. Ralph
i'll chip in too
I will give 15 canadian dollars as well. It's been 7 years since this has been requested, enough is enough.
For a serious solution, expect my 25 € as well! It's one of the bugs I hate the most in KDE.
Please stop using Bugzilla as a pledging-for-work location for this wish-list item. Unless the developer WANTS to code this up, understand this is THEIR prerogative, and criticising the devs by saying they "aren't doing anything" is both rude and unbecoming of a KDE community member. Remember, finding an itch and coding it is what F/OSS is all about, and KDE is driven as a meritocracy. In other words, if you want this, either hire someone to do it (and not through Bugzilla) or code it up yourself. With that said, we get to the next gripe I have about all the posts on this item of late: this is neither the forum, or the mechanism for doing pledges-for-code. This tool is for triaging bugs and wish-lists for software. Please do me and all the others that are involved with this bug a favour and take it to another forum. Thanks.
then maybe oswal should not have asked for people to pay to have this feature? see comment #81.
how tenacious can one be
oh for effs sake. kdelibs4 *has* a pam_open dbus call into kwallet, but no pam module to call it???? wtf?
can someone please close this as "worksforme". there's a "pam_kwallet" in kde/playground/base and a pam_dbus_launch at http://code.confuego.org/index.php/p/pamdbuslaunch/ With those two modules, single sign on *works*.
Until it is out of playground I wouldn't say it can be considered finished. pam_kwallet doesn't appear to have had any commits in almost a year and a half.
...so? i've build the stuff just now and tried it, and it works fine. and the dbus call that it uses has been in kwalletd since 4.4.2, so of course the accompanying pam module is *old*.
This is known to work but due to various reasons it has never been released. Number one of the reasons is that the D-Bus developers don't like the way of starting the bus using a pam module and think it's plain wrong.
If the developers don't think it should be used widely, which is what it means to be in playground, I think we should listen.
Michael, is pam_kwallet your project, too? I didn't even know it existed and like to have a look at it but it looks like both gitweb.k.o and anongit.k.o are down and the project isn't on projects.k.o. Any chance to have this added to projects.k.o?
Maybe the dbus developers should think about providing a way to start the dbus service that is not "plain wrong"? all I can say is, in this day & age a single-sign-on method for kwallet is a must have. The one with the pam modules works. good enuff for me.
@Malte: yeah, I developed both modules to fix this bug quite a while ago. I haven't worked on it since its last commit. Not sure if it's actually worth it - when the time is ready it should probably be adapted to work with the new secret service.
Support for Secret Service is pending for two or so years now. That's not meant as a criticism of your work, I'd just like to have something which just works now and until the real thing arrives. I have an idea on how to circumvent the dependency on pam-launch-dbus and might hack pam-kwallet to make it work in a spare minute. Ah, gitweb is back. I can see some work happening in ksecretservice.git but can't find a pam[-_]kwallet.git (anongit is still down).
what is this "ksecretservice" you guys are talking about? and like Malte already said... pam_kwallet works *now*, not *at some point in the distant future*.
Secret Service is a joint specification by KDE's KWallet and Gnome's Keychain to have a unified API for unlocking the secrets on logon and accessing them later on. You can look it up here: http://standards.freedesktop.org/secret-service/
looks quite intriguing.. ...but... are there actual working implementations yet?
Yes, ksecretservice is being released as we speak. They are just trying to decide where to put it in the git tree.
so what do i do with it as of now? replace kwallet with it?
Nothing, there will be more information once it is decided how it is going to be handled. At best it will not be available until 4.8, at worst not until frameworks.
that's what I expected.
grmbl. seems that pam_kwallet does not want to work in a NIS setup :(
Is there an easy way for regular users such as myself can get this thing in playground working? The continuing lack of single sign on is absurd.
Having found this ticket (and the lack of action on it!) I wrote myself a small script for the kde/Autostart folder that simply talks to kwallet and calls kerberos kinit (with appropriate kdialog prompting if needed). Seems to work ok for me as a workaround.
Finally, there's light at the end of the tunnel :) I've just found this in the kde-4.8 RC2 release notes: "KSecretService optionally enables a shared password storage, therefore making your saved passwords available to many other applicatios, leading to a more secure system and better integration of non-KDE apps into the Plasma Workspaces and KDE apps into non-Plasma workspaces." (see here: http://www.kde.org/announcements/announce-4.8-rc2.php )
kSecretService was mentioned already in this thread and information is available here http://techbase.kde.org/Projects/Utils/ksecretsservice http://standards.freedesktop.org/secret-service/ http://dot.kde.org/2011/12/22/kde-makes-first-48-release-candidate-available-adds-secret-service However as its still early on in development I did not want to wait hence writing something that just works now so I have ssh/kerberos keys/passwords all working from kwallet on login.
Hi nick, Can you please provide your workaround script here ? I still won't wait until the ksecretservice is ready for use. Thanks (In reply to comment #113) > Having found this ticket (and the lack of action on it!) I wrote myself a small > script for the kde/Autostart folder that simply talks to kwallet and calls > kerberos kinit (with appropriate kdialog prompting if needed). Seems to work ok > for me as a workaround.
Hi, Sure. I will finish up another of my use-cases (I want it to automatically get a kerberos key after a VPN has been activated) and then write it all up. (In reply to comment #116) > Hi nick, > > Can you please provide your workaround script here ? > I still won't wait until the ksecretservice is ready for use. > Thanks > > > (In reply to comment #113) > > Having found this ticket (and the lack of action on it!) I wrote myself a small > > script for the kde/Autostart folder that simply talks to kwallet and calls > > kerberos kinit (with appropriate kdialog prompting if needed). Seems to work ok > > for me as a workaround.
My scripts are here: https://github.com/rnc/kde-scripts Hope they help - works for me ;-)
Hello Nick, I took a look at your scripts. They use a password stored in kwallet to initialize kerberos tgt (kinit). Isn't it? This bug is about the "oposite": open kwallet using the login/pam password. Maybe others got confused as I did. The idea is that pam could provide the passoword in order to open kwallet (or ksecretservices) without asking the user again for a password, just after it has already provided one for its login process. BTW, if you want to always use kerberos, why not just use pam_krb5.so? You will authenticate using the kerberos password and will get the TGT "for free". If you use kerberos from AD, pam_winbind.so also provides the TGT (just like kinit) and allow other nice features like offline authentication.
(In reply to comment #119) > I took a look at your scripts. They use a password stored in kwallet to > initialize kerberos tgt (kinit). Isn't it? Yes true. > This bug is about the "oposite": open kwallet using the login/pam password. > Maybe others got confused as I did. The idea is that pam could provide the > passoword in order to open kwallet (or ksecretservices) without asking the user > again for a password, just after it has already provided one for its login > process. > > BTW, if you want to always use kerberos, why not just use pam_krb5.so? You will > authenticate using the kerberos password and will get the TGT "for free". If > you use kerberos from AD, pam_winbind.so also provides the TGT (just like > kinit) and allow other nice features like offline authentication. Ah ok sorry :-) Well not wasted as its useful for me ;-) Thanks for the hint; might look at it.
what happened to KSecretService? I'm running KDE 4.8.1 on openSUSE 12.1 and there are no packages available.
besides, I don't think that changing from the old system to ksecretservice would even cover the topic of this request at all... this request is about how people do not want to enter their password twice in a row. once to log in on their computer, the second time when kopete or chokoq gets autostarted.
*** Bug 307396 has been marked as a duplicate of this bug. ***
so... we're at KDE 4.9.4 by now; KDE 4.10 is in feature freeze... Will there be a reliable single-sign-on in it?
setup your kwallet to use an empty password, that way you dont have to type the password during the login. Yes, its not secure, but its way less annoying
I hope you're joking...
I'm actually serious. I'm no dev and i doubt anybody works on this. So my only practical solution i found is to set an empty password. It was either that or not using kwallet at all. Kwallet is useful so i opted for the password less version (and do so for all computers i install with KDE, the double login is not acceptable for the average user)
The way I work around this in a relatively secure way is to use full-disk encryption (LUKS). Then you can set KWallet without a password, and you can even set KDM to log you in automatically without a password (with the screensaver lock enabled at startup perhaps). This way, the only password you'd need to enter is the one used to decrypt your entire partition. This is obviously vulnerable to malicious applications running on your system once it is booted and you've entered the decryption password. But then again, even KWallet is vulnerable to malicious applications running on your system once you're logged in anyway, because all an application needs to do is to request KWallet access, and then simulate a click on your behalf on the "Always allow" button. However, at least this setup is secure against attacks while your computer is off (someone steals your laptop or something).
as a matter of fact KWallet is not very secure in the first place. With a password it is secure as long as you have not opened the wallet. Once the wallet is open it is unsecure in the following (obvious) ways: * all information on how to read the passwords has to be in memory. Reading the memory would provide the passwords. Turning of the system would not protect against it (cold boot attack [1]) * there is no authentication between applications and the wallet. Establishing authentication is hardly possible on an open system. Overall I would say if you do not fear that someone would get access to your turned off system there is no need to have a password. That is a desktop system is probably fine without a password, but on a notebook which could be stolen one should consider using one. There is probably a higher risk from malware interacting with the open wallet than that someone steals the hard disk. In most cases the mentioned LUKS solution is excelent, though I just need to point out that it's of course also breakable by cold boot attacks. I'm not a KWallet developer, just subscribed to this report and interested in IT security (was my major in my Masters program). If you know think that KWallet is insecure: be aware that these are problems probably visible in all password store solutions. The security model of Linux is "if it runs, it's trusted", which means one does not have to consider malicious software. [1] http://en.wikipedia.org/wiki/Cold_boot_attack
Were there any attempts to implement it since pam_kwallet? Of course, starting session bus from pam module isn't a good idea. But what's the problem with this approach: 1. From pam module, start a process and pass password to it 2. The process waits for "ready" signal from kwallet (signal can be passed, for example, using sockets) 3. At some time kwalletd starts, sends signal to the process 4. The process sends password to kwallet (using d-bus call)
(In reply to comment #130) > But what's the problem with this approach: Sounds good. I also had an idea that is (in theory) even simpler: Just start KWallet from PAM and pass it the password (e.g. via stdin).
This is almost how it's done in gnome-keyring. Take a look on it's code and especially on comments about pam. I'm not sure that kwalletd started from pam module will be able to work.
I have a little enterprise and we use Linux (Ubuntu to be exact) since 2010. I've recently tried Kubuntu and felt in love with it, so I began to try everything in my new KDE system... and what I get just after an automatic login? the system is requesting for my password?? I mean, come on... there's no way KDE is the only desktop out there without a full automatic login? even windows does that... Excluding this, KDE is absolutly marvelous. Devs: IMHO if you want to catch all the possibles users, you have to let them use their system as they want... and lots of normal users just does not want to EVER put a password at any time on their computers. So PLEASE... make this happen :)
@jpxsat, I'm no expert in pam/kwallet but this bug is not related to your request. The password in kwallet is used to protect the sensitive data that are stored inside the wallet. The request in this bug is: "if I used the same password for kwallet and the user login, why not copy this password from the login and use it to try to open kwallet?" The autologin does not store your password and use it to login normally. It just "su" to your user and runs KDE. So, If you use autologin, the system does not know your the password. If kwallet is protected, it need its password in order to read its data. If security does not concern you, you need to use kwallet without a password. However, be warned that anyone with access to your filesystem would easily read all your passwords stored in kwallet.
@Luiz Angelo De Luca Thanks to your comment I tried (never wanted to, but now I did) turning off KWallet. It seems that it solves my problem. I still think that my issue was somehow related to this bug, because if I wanted for KWallet to open automaticly with autologin should not this be the "bug" to fix? Thanks for giving me the idea for turning off KWallet :)
*** Bug 291933 has been marked as a duplicate of this bug. ***
Ubuntu Linux have feature for user home folder encryption, it works with password that user enter on login, this is done via pam_ecryptfs.so module. So nobody can decrypt data without knowing user password. Maybe kwallet can reuse this method for opening kwallet via user password?
... kde 4.10.5 by now, KDE 4.11 is in RC2, any signs of process on this one?
KDE 4.11.2 by now, any progress on this? The pam modules don't work with NIS users...
I managed to get pam_kwallet to work with NIS, for details, see here: http://linux.eregion.de/2013/10/26/kwallet-single-sign-on-at-last/
I suggest pam_dbus_launch and pam_kwallet make it into KDE 4.12 or KDE 5.0.
This is one of the most wanted features in KDE since 2005 - and the only one that really annoys me about KDE, which otherwise is an outstanding DE. Hope it gets implemented soon :)
http://linux.eregion.de/2013/10/26/kwallet-single-sign-on-at-last/ provide very good solution, that solves this issue, tested and works for many people. But now it available only for OpenSUSE, other Linux system don't have easy-to-install ways. Can you import this modules to future KDE SC releases?
I would like to point out that gnome 2.x on Red Hat Enterprise Linux 6.x has been doing exactly this for the gnome password storage for ages. So ... if the likes of red hat and gnoe can do this, should the KDE team really waste 8 years in a moralistic discussion about its emotional merit and security value? If security worries you, make it so that the feature is OFF by default, and the user gets a warning first time they enable it.
Is there anything planned for frameworks 5 in that regard? I would agree to make an option for this (and try to make it as secure as possible), but disabling it by default in case of security concerns.
(In reply to comment #145) Seems so: https://plus.google.com/+%C3%80lexFiestas/posts/CarwXy8v85b
For those that haven't yet noticed, looks like Kubuntu 14.04 LTS has this working: "PAM KWallet git20140410 New single sign-on capabilities for the password manager KWallet. Allowing new wallets to be automatically be created on first login and automatically unlocked on subsequent logins. " Hopefully other distro's and upstream will pick this up soon. https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes/Kubuntu#PAM_KWallet_git20140410
Thanks, very cool! But I can't find any howto or manual how to use and configure it. Divan Santana, can you post short description how I can I enable auto unlocking KDE Wallet on login for old wallet on Kubuntu 14.04? Thanks.
wow
Some general instructions can be found here (I wrote the post): https://www.dennogumi.org/2014/04/unlocking-kwallet-with-pam/
unsubscribe
@Luca, I have tried to build and install that module according to the instructions in your blog post... doesn't work. And no error messages either. Is there a way to switch it to verbose or such?
Arch x86_64: pam_kwallet(systemd-user:session): pam_kwallet: open_session called without kwallet_key
I am not sure how to debug this, as I figured the steps with trial and error. Can you try installing socat?
I'm not familiar with socat. Could you explain, how to use it in this case?
The Ubuntu package lists it as dependency. I forgot if I had it installed at the time of my tests.
What do you mean by "Ubuntu package lists"?
unsubscribe On Fri, Apr 25, 2014 at 11:53 AM, imraro <imraro@gmail.com> wrote: > https://bugs.kde.org/show_bug.cgi?id=92845 > > --- Comment #158 from imraro <imraro@gmail.com> --- > What do you mean by "Ubuntu package lists"? > > -- > You are receiving this mail because: > You voted for the bug. >
The pam-kwallet package in Ubuntu has socat as dependency. Whether this helps or not I do not know as there is no documentation and this stuff is low level.
Nothing has changed after installing socat.
(In reply to comment #151) > unsubscribe Remove yourself from the CC list.
(In reply to comment #159) > unsubscribe > > You are receiving this mail because: > > You voted for the bug. actually, remove your vote from the bug
Apparently to get this to work you need 3 commits that did not make into 4.13 and will likely be in 4.13.1. More seriously, I would suggest people that need this to use Kubuntu, that somehow got this to work. I can't even reproduce my work on another machine, so I'm guessing that either the author or someone with deeper PAM knowledge steps in, or it's just a waste of time.
FWIW, I updated the blog entry with more possible suggestions. But at least for me I can't get it to work with KDM.
I'm using lightdm and git-repos for pam_kwallet )
(In reply to comment #163) > (In reply to comment #159) > > unsubscribe > > > You are receiving this mail because: > > > You voted for the bug. > > actually, remove your vote from the bug Removing of a subscription and removing of a vote is not same, isn't it?
(In reply to comment #160) > The pam-kwallet package in Ubuntu has socat as dependency. Whether this > helps or not I do not know as there is no documentation and this stuff is > low level. the socat is not strictly needed by pam_kwallet itself, but by the startkde script. But only when pam_kwallet is installed, too. (In reply to comment #161) > Nothing has changed after installing socat. The following lines are needed in /usr/bin/startkde and are missing in openSUSE (ubuntu and fedora already have them): if test -n "$PAM_KWALLET_LOGIN" ; then env | socat STDIN UNIX-CONNECT:$PAM_KWALLET_LOGIN fi
Yes, my bad on that. I forget I run git master on my main box, which has already these commits in (but 4.13 hasn't them).
Created attachment 86268 [details] Adds pam_kwallet support to startkde
I've set this up and it works, but only for local users. Does not work for network user accounts (i.e. NIS). Don't have a LDAP server here to test that.
On which distro did you set this up? Any changes from what I wrote? So that I can amend the guide as necessary.
I'm using openSUSE 12.3 here, no changes from your blog post. when I login using a locally set up account, it works; logging in with a user account from NIS it doesn't.
ok now i'm at the "huh?" stage of this; two identical machines, and I literally copied the config and libraries from one to the other, and on one computer it works for both local accounts and NIS, and on the other it doesn't work for any of them.
In data sabato 26 aprile 2014 07:59:01, hai scritto: > computer it works for both local accounts and NIS, and on the other it > doesn't work for any of them. I've had the same issue when trying to generalize the guide. I guess we need a PAM expert to debug this...
Oh come on guys, bugzilla is not a forum.
In data sabato 26 aprile 2014 08:40:39, hai scritto: > Oh come on guys, bugzilla is not a forum. Indeed, we have the KDE Community Forums. I've taken the liberty of creating a post discussing the configuration, to keep this entry cleaner (although anyone could have posted that, instead of just saying "bugzila is not a forum"): http://forum.kde.org/viewtopic.php?f=14&t=120843 Please direct further discussion on how to hook KWallet with PAM there.
Single sign-on no longer works for me when I upgraded to Kubuntu 15.04 and plasma 5.3. Does anyone know if this is because of a problem with Kubuntu or because the feature hasn't made it to KDE 5? (Or maybe the feature is still there but I need to enable it somehow?)
Looks like pam-kwallet needs to transition to kwallet5. But this needs to be tracked elsewhere.
As Orion suggested, I filed a new bug to request that this feature is revived in KDE 5. See Bug 349003. (Am I the only person who misses this feature? This thread is awfully quiet considering the number of votes it got...)
(In reply to Leon Maurer from comment #180) > As Orion suggested, I filed a new bug to request that this feature is > revived in KDE 5. See Bug 349003. Thanks. > (Am I the only person who misses this feature? This thread is awfully quiet > considering the number of votes it got...) No, but most have given up on requesting this common feature.
> (Am I the only person who misses this feature? This thread is awfully quiet considering the number of votes it got...) I very want to vote, but didn't see Vote function in Bug #349003 but in this bug I can vote. Maybe you post the bug with wrong type?
I just use KWallet without password because I don't want to wait single-sing-on next year or two and I don't want to type my password again.
This request is from 2004. Expecting this feature in one or two years is quite optimistic.
This thread is dead. Checkout the new bugreport for KDE 5 (Bug 349003). It looks like the feature may be added back soon; there's already a patch.
(In reply to Leon Maurer from comment #185) > This thread is dead. Checkout the new bugreport for KDE 5 (Bug 349003). It > looks like the feature may be added back soon; there's already a patch. Great news, but then why is this bug still open? Can we just close it as WONTFIX / OBSOLETE?
That seems reasonable to me. We should probably put this thread out of its 10+ year misery.
http://martys.typepad.com/blog/2015/07/kwallet5-can-be-auto-unlocked-during-login-again.html