> Anyway, here's the steps to reproduce : [...] > So here is a possible security hole : if you want that somebody without > an encrypted home dir, shouldn't login, then he can ... aïe.
No, that was not the intended behaviour, everybody should be able to login. > I wrote the patch attached to partialy correct this behavior : at least > evrybody with or without an encrypted home dir will be able to log in. I think this is fixed in the new version uploaded yesterday to unstable. Can you check that? > I take the time to correct some warnings (not all, but most of them) > too. > > Ok, back to the default conf file : why the maintainer let it's user > name in the file ??? (and not commented). why not? Anyway, the example has now a generic "user" and commented. > I suggest too, to put somewhere that the password for the encfs > NEED to be the SAME as the unix login ... that's a serious weakness in > my mind ... if somebody was able to crack the login password, it could > read the encrypted data's ... So in the same time, I suggest to put a > warning, to explain that you need to put the .encfs5 on another device > like an USBkey + automount it for reading this file (a link from > /home/.enc/encrypt/.encfs5 to /var/autofs/removable/uba/encfs5, could be > a start for a better security) NOTE : this can't work with actual code. This is not addressed in the last upload, neither the other fixes unless upstream has fixed them (which did with a couple of them). So, if you agree with me that the main issue is solved, we can downgrade this bug.
