Andrew Morgan wrote: > > To what extent is this module backwardly compatible with the old one? > > I don't personally have any test for this module, so it would be nice to > see some other folk try it out/report problems etc., and then > effectively vote on it replacing the original.. I can't say this myself (not an "independant" guy :). All the extensions I made was mentioned in my first post. Support for wildcards consists of about 5 lines of code and can be easily removed (together with negation and homedir support since them are useless without wildcards -- another ~10 lines). Another incompatibility may be in handling of lines in listfile -- I prefer to strip spaces from a line before comparing it with an item. With this, lines like " user" or "user " will match while them wasn't matched before (first form can in principle be used as a comment). Also, I prefer to skip comments in listfile (like "#user"), so if for some strange reason someone will try to match item "#user", it will never match (without wildcards, with them that can be written as "\#user" or "[#]user"). Also, my variant differently handles file=some where some does *not* start with a slash (/). I consider this a bug in current pam_listfile, since in that case module will try to open file named "some" in *unknown* directory. My variant treats this as a direct list of values, and I personally found this very useful. With wildcards support, another incompatibility (also mentioned) could be with wildcard characters (*?[\) -- I do not know if someone have items with that characters... Again, wildcard support (useful for me) can be removed (see above). Arguments also handled differently: module checks if some value does not specified twice or more. For example, it is legal with current pam_listfile to have ... pam_listfile file=/a file=/b ... (in this case, /a is just ignored). With my variant, this is an error. Also, *parameter* errors treated as errrors, returning PAM_SERVICE_ERR, not that was given in onerr= parameter. Seemed to be not appropriate to return error about invalid parameter using that parameter's value... :) And there may be difference with logic of apply= *and* if some information is *not* available (e.g. if user is unknown (current variant will segfault, I'm not shure I should implement this "feature" :), or if primary group is unknown (the same), or if user/group in apply= is unknown, or if there is an error getting username from pam etc). *Only* errors handled differently, normal logic is the same. BTW, this is very small module. I was surprized how one can have so many bugs in so little module. It have no "big logic", and both implementations can be compared just looking to code. Really -- 10..12 Kb (mine is heavily commented) is not a strong place for a testsuite... I tried to follow original as carefully as I can, where it was appropriate (minus bugs/enhancements/wrong original logic). Regards, Michael.
