Re: kwallet-pam >= 5.18.4 and ecryptfs homes
> > Opinions? It's a tough situation, with no good answer. >SOLUTION 2: > * Ignore it and hope people will read my blog https://tsdgeos.blogspot.com/2020/05/kwallet-pam-5184-and-ecryptfs-homes.html We can simplify the bit about needing another user. If you use sudo mount --bind / /tmp/IAmACoolNewMount you should be able to retrieve the file in the unmounted /home That would then potentially allow this to be a shipped script to run. Albeit user interaction and root would still be required, but a run-once migration might be easier to write and maintain than long term hacks in the pam side.
Re: kwallet-pam >= 5.18.4 and ecryptfs homes
P.S: Remember to CC me El dilluns, 4 de maig de 2020, a les 21:11:22 CEST, Nate Graham va escriure: > On 5/3/20 4:02 PM, Albert Astals Cid wrote:> Problem with SOLUTION 1 is > that it adds lots of code in a relative "sensitive" piece of code like a > pam module for for what it is a one time thing. > > Problem with SOLUTION 2 is that it's not a solution :D > > > > > > Opinions? > > I feel pretty confident in your skills at implementing option 1 safely. > :) Here the problem is that i actually need to be able to reproduce the issue myself first, i guess i can try installing some old KUbuntu and then upgrading in a VM. Let's try to give it a try. > Once the code is pushed out to users in 5.18.5, could we remove it in > master to avoid an ongoing maintenance and security issues? No, we need it "forever" so that people updating from < 5.18.3 to >= 5.18.4 don't face the problem. Cheers, Albert P.S: Remember to CC me > In any event, it seems like we don't really have much of a choice since > as you mention, option 2 doesn't actually solve the problem for the > typical user. > > Nate >
Re: kwallet-pam >= 5.18.4 and ecryptfs homes
On 5/3/20 4:02 PM, Albert Astals Cid wrote:> Problem with SOLUTION 1 is that it adds lots of code in a relative "sensitive" piece of code like a pam module for for what it is a one time thing. Problem with SOLUTION 2 is that it's not a solution :D Opinions? I feel pretty confident in your skills at implementing option 1 safely. :) Once the code is pushed out to users in 5.18.5, could we remove it in master to avoid an ongoing maintenance and security issues? In any event, it seems like we don't really have much of a choice since as you mention, option 2 doesn't actually solve the problem for the typical user. Nate
kwallet-pam >= 5.18.4 and ecryptfs homes
Remember to CC me, I'm not subscribed to the list Sadly, a fix i made for Plasma 5.18.4 so that kwallet-pam reads/stores the salt file inside the encrypted home dir (if there is one) means that if you had used kwallet-pam < 5.18.4 and now use kwallet-pam the salt file is not found and your kwallet is not auto-opened on login as you wanted. SOLUTION 1: * read the salt file in the "authenticate step" (encrypted home if there is one still not mounted), keep it in memory * Read file the file again in the "open_session step" (encrypted home if there is one is now mounted), if there is no salt file, write it with what we have in memory Problem A) The "old" file is still there outside the unencrypted home, which is not optimal Problem B) This doesn't help people that have already updated to 5.18.4, since those will have a new salt file already in place Potential solution to A) Keep the file descriptor for the "salt file from authenticate step" and if we find we have to use that file, delete or empty that fd This is assuming that fd to "now unexisting paths because a folder was mounted or" are still valid/usable Potential solution to B) If opening the wallet failed and there was a different salt file in the authenticate step file try to use the contents of the old salt file to open the wallet, if that succeds show a long dialog with instructions of what they should do (i would rather not overwrite salt files just in case) SOLUTION 2: * Ignore it and hope people will read my blog https://tsdgeos.blogspot.com/2020/05/kwallet-pam-5184-and-ecryptfs-homes.html Problem with SOLUTION 1 is that it adds lots of code in a relative "sensitive" piece of code like a pam module for for what it is a one time thing. Problem with SOLUTION 2 is that it's not a solution :D Opinions? Cheers, Albert Remember to CC me, I'm not subscribed to the list
