OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: pam_listfile is *buggy* (and a replacement)
From: Michael Ju. Tokarev (mjttls.msk.ru)
Date: Sun Dec 17 2000 - 14:56:19 CST

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.

_______________________________________________
Pam-list mailing list
Pam-listredhat.com
https://listman.redhat.com/mailman/listinfo/pam-list