Comment 14 for bug 307019

Yeah, I forgot that eCryptfs requires the real password to work. It also needs the old password BTW, so this will never work if the admin changes the password, since he's not likely to know the old one. Thus, I'm not sure it's worth using the backends at all. Ideally, D-Bus could provide us with a secure connection (why isn't that the case?); we could also use a pipe, should be possible but will require some work.

If your goal is to get this fixed for Alpha 6, better go with a client-side solution. Just patch the GUI to call the required program. Then, ask for the old password if the user edited the new one (maybe that's not required if the folder is unwrapped).

I'm planning to redesign the GUI in the next cycle, and I may well use something like the about-me dialog to change passwords, so that may help in the middle-term. In the long term, I'm not sure we really need to pass the clear password to the backends, since it would only be useful for eCryptfs, which does not fit in our authentication model since the admin needs the original password. I'd eventually go for a solution where eCryptfs is setuid so that anybody (here the GUI) can ask the user the old and change it if it's the right one. No need for other checks, I guess. If the admin changes the password on it own, eCryptfs should show a dialog on start asking for the old password so that it is then changed. Can you find something better?

PS about the gst: I can perfectly understand your anger against them - so do I. They suffer from many little bugs that plague our user experience. But I don't think the design is broken at all: the future seems to be PolicyKit over D-Bus, and then sending the password hashed is the best solution - until eCryptfs appears, where we have to adapt. I can't see how using PAM would really help, apart from this case.