to accept input. Otherwise, there is a small but non-zero chance that
input provided after the prompt appears is discarded when we flush the
tty buffer.
Submitted by: Brooks Davis <brooks@freebsd.org>
git-svn-id: svn+ssh://svn.openpam.org/svn/openpam/trunk@948 185d5e19-27fe-0310-9dcf-9bff6b9f3609
introduced when pam_getenv() was (needlessly) rewritten as part of
r913. Rewrite pam_getenv() again (but correctly, this time) to reduce
the number of times we iterate over the same string. Add a few unit
tests for pam_{get,put,set}env(), including one which would have
caught the bug.
Credit goes to Tim Creech <tcreech@tcreech.com> for discovering and
reporting the bug.
git-svn-id: svn+ssh://svn.openpam.org/svn/openpam/trunk@943 185d5e19-27fe-0310-9dcf-9bff6b9f3609
leaking a small amount of memory for every PAM session.
While there, eliminate an unnecessary variable.
git-svn-id: svn+ssh://svn.openpam.org/svn/openpam/trunk@918 185d5e19-27fe-0310-9dcf-9bff6b9f3609
when compiling code that calls the function, but also when compiling the
function itself. This means that NULL checks in the function trigger
condition-always-false warnings. We have a choice between disabling these
warnings, removing the __nonnull__ annotations, or removing the NULL checks.
We prefer to keep the annotations and warnings and remove the checks. In
all cases, passing NULL to the function in question will result in a
segmentation fault, which is often easier to debug than an error return,
especially when most of these checks were for the PAM handle, which can only
be NULL if the caller ignored an error return from pam_start().
git-svn-id: svn+ssh://svn.openpam.org/svn/openpam/trunk@913 185d5e19-27fe-0310-9dcf-9bff6b9f3609
instead of assuming (incorrectly) that it returns non-zero on success.
Bump dates as needed.
Reported by: Patrick Bihan-Faou <patrick-fbsd@mindstep.com>
git-svn-id: svn+ssh://svn.openpam.org/svn/openpam/trunk@902 185d5e19-27fe-0310-9dcf-9bff6b9f3609
can actually ever occur, but the extra free() is harmless, provided we
make sure not to free() something we're still using.
git-svn-id: svn+ssh://svn.openpam.org/svn/openpam/trunk@877 185d5e19-27fe-0310-9dcf-9bff6b9f3609
for chains that are still empty after the requested policy was loaded.
git-svn-id: svn+ssh://svn.openpam.org/svn/openpam/trunk@862 185d5e19-27fe-0310-9dcf-9bff6b9f3609
size of the buffer is not necessarily known, and which can replace the
"memset(str, 0, strlen(str))" idiom. Use it to clear buffers which may
have contained authentication tokens.
git-svn-id: svn+ssh://svn.openpam.org/svn/openpam/trunk@803 185d5e19-27fe-0310-9dcf-9bff6b9f3609
1. Finish a comment which was meant to describe the four different
termination conditions for the loop in openpam_parse_chain() but
ended in mid-sentence.
2. Ensure that errno is consistently set to EINVAL if a syntax error
is encountered in the policy file.
3. If openpam_load_module() fails because the module could not be
loaded, set errno to ENOEXEC instead of ENOENT. This closes a hole
where a missing module or a typo in a module name would cause the
corresponding chain to fail open. Normally, if the policy exists
but cannot be loaded, openpam_load_chain() will return an error,
and openpam_configure() will discard any partially constructed
chains. However, openpam_load_chain() interprets ENOENT to mean
that the policy was not found, so it does not immediately return an
error, the partially-loaded chain is not discarded, and the policy
is incorrectly considered to have been successfully loaded.
4. Ensure that errors encountered while parsing an included policy are
correctly propagated to the original policy, and that ENOENT while
processing an include directive is a hard error, not a soft error.
CVE-2014-3879
git-svn-id: svn+ssh://svn.openpam.org/svn/openpam/trunk@795 185d5e19-27fe-0310-9dcf-9bff6b9f3609
filename is much larger than it needs to be. However, this might not be
the case in the future. To be safe, add a length check after strlcpy().
This should silence a Coverity warning about possible array overflow.
git-svn-id: svn+ssh://svn.openpam.org/svn/openpam/trunk@745 185d5e19-27fe-0310-9dcf-9bff6b9f3609
as an OATH OTP key, since liboath uses openpam_readline() to read the
keyfile)
git-svn-id: svn+ssh://svn.openpam.org/svn/openpam/trunk@703 185d5e19-27fe-0310-9dcf-9bff6b9f3609
even more badly broken when the dynamic loader was rewritten in March.
Reimplement it the way it was always meant to work (but never did):
If --with-modules-dir was specified, modules will be installed in that
directory and the dynamic loader will look for them there. If it was
not specified, modules will be installed in libdir and the dynamic
loader will use the standard search path (/usr/lib:/usr/local/lib). In
both cases, a policy file can still name a module by its full path.
git-svn-id: svn+ssh://svn.openpam.org/svn/openpam/trunk@690 185d5e19-27fe-0310-9dcf-9bff6b9f3609
unfortunate amount of code duplication between the tty and non-tty
paths, but the alternative is greatly increased complexity.
git-svn-id: svn+ssh://svn.openpam.org/svn/openpam/trunk@687 185d5e19-27fe-0310-9dcf-9bff6b9f3609
debugging macros, and sets the initial value of openpam_debug to 1.
This effectively gives the user a choice between no debugging at all,
or drowning in debugging messages from every part of the system.
Assuming that the primary use case for debugging is to allow admins to
troubleshoot their policies by adding the debug option to selected
pam.conf entries, remove the initialization of openpam_debug to 1.
This allows integrators to ship OpenPAM with OPENPAM_DEBUG defined
without spamming /var/log.
git-svn-id: svn+ssh://svn.openpam.org/svn/openpam/trunk@684 185d5e19-27fe-0310-9dcf-9bff6b9f3609
Dag-Erling Smørgrav