Hi, I started this mail yesterday ... 24h/day is not enough since the past few days :(
First of all, I forget to state in the documentation that the external program also needs to send a ".\n" on a new line after sending the "required" fields. 1) "Don't use recent password" feature: I did not want to focuss on this feature yet but since it came up on the list, lets do it ;-) This was actually the next thing I thought of doing in terms on contribution to Samba!!! a) If we want the password-quality script to handle this, I think we'll all agree, storing clear text password is really not a good idea. Perhaps the interface should provide the new encrypted passwords to the external program -- if administrators don't have "easy access" to the encrypted password, some will probably endup use the cleartext one :( b) My idea was to incorporate this directly within smbd creating a database, tdb? but I have no clue on the specifications of tdb database -- perhaps I'm writing something really stupid here :) If it's not possible with tdb, I guess we could use something else. I would be much better, in term of security, to store the old passwords using MD5 or even Blowfish (is it legal to distribute such encryption mechanism in Samba -- I'm thinking of the US encryption law restricting exportation). Any experts around? I also think that such of "module" requires to remove all data from the "old password database" when a user is deleted. Or we provide a tool for systems administrators that checks if there is still a match between what's in the "old pw db" and the "pdb" / smbpasswd file, etc!?! If you have a clue now on how to achieve this, great -- otherwise we'll think of this when we get there! 2) PAM module I'll leave this to someone else. I really think PAM rocks but if we want to support this new feature on every supported OS by Samba, I think we should not go PAM. Is PAM standard on all Unix flavors? Will Windows ever support PAM? (Ain't someone in this world trying to port Samba to Windows? -- I wouldn't be surprised, LOL). Ain't people moving towards pdb LDAP backend using the included LDAP support in Samba instead of using PAM? 3) "Failed" script Yes, if the script fails to run or return an exit status != 0, smbd deny the change request. 4) Root / non-root We could add an attribute "password quality runas root (true/false)" in smb.conf . Should we? 5) "Protocol" Do we agree on the following for "version: 1\n"? - Version starts @ 1 - Space added ... "Field: value\n" -- External can return with or without a space. I think on the answer we can be a little bit "flexible", is that fine? - Send empty string value if a "value" is not available: "Fullname: \n" - I agree with Andrew -- "string protocol is much easier to implement / debug". I don't know how the fullname will be passed to the external if there are "funky" characters, I know this is not a problem with the other Fields. Perhaps for release #1 we don't send the "fullname"? If we need some type of "encoding / decoding" mechanism, shouldn't we use something already "very popular". If it's too complicated, people won't use it. - Returned NTSTATUS. Allow both string and hex or not? The code presently does this: ... pnstatus is the "NTStatus" returned value. presult is the "Result" (debug info) returned value. /* Match returned NT status from external program */ ntstatusmap = nt_status_string_to_code(pntstatus); if NT_STATUS_EQUAL(ntstatusmap, NT_STATUS_UNSUCCESSFUL) { DEBUG(1,("Undefined NTSTATUS %s received from %s\n", pntstatus, cmdname)); DEBUG(1,("user %s could not change password - %s\n", username, presult)); return NT_STATUS_ACCESS_DENIED; } if (!NT_STATUS_IS_OK(ntstatusmap)) { DEBUG(1,("user %s could not change password - %s\n", username, presult)); return ntstatusmap; } return NT_STATUS_ACCESS_DENIED; If tomorrow there is a new "return code" available, it will work once it is added in "nterr.h". When I first wrote the documentation I wrote something like: "we suggest that you use one of the following NTSTATUS for this context" but I figured perhaps the protocol should not be flexible. Either when there's a new NTSTATUS for this context, we had it in "nterr.h" and password-quality.c OR we leave it like it is now, i.e. accept anything defined in "nterr.h". Honestly, I'm still not sure if we should allow both. I know I don't really like the idea of smbd returning something not defined in "nterr.h". True "protocols" always use numeric values. "440 - File not found" ! If we have to modify the source code when we need to add a new supported returned value, I think we'd rather just need to add this new "value" in nterr.h and Voila! - Password field -- "injection attacks" No answer yet on the message (Password changing - root bug?) I sent yesterday night (today early AU time!!!) on the mailing-list. If control-chars are "illegal" , I'll check for this and return, I guess NT_STATUS_ILL_FORMED_PASSWORD would be appropriate here. Thank you for your valuable comments. I look forwards to read yours. Pierre B.