Btw, the decision upong ignore return code opposed to bad/die is entirely
delegated to the application, and not to pam itself. And here's
login/gdm/whatever are behaving that way. Hence why pam_deny is always good to
have.
The stack is considered to be 'failed' only if you get a bad or a die,
Look, you could make it even simpler for testing it.
Just take a vanilla 7.04 or 7.10, edit common-account and common-auth
and substitute required with sufficient (in the only pam_unix.so line)
and you'll get the same results.
--
pam configuration could use safer defaults
So, I can confirm that the following configuration leads to local users (both
via tty consoles and gdm) to login with a blank password.
Here are the modified pam files, all the others are left untouched, the
error here is having 'sufficient + sufficient' in both common-account
and common-auth,
Here are the modified pam files, all the others are left untouched,
Ok, sure; in that case the sufficient + sufficient is not the complete
stack, and the return value is controlled by the presence of other PAM
modules listed in the per-service config files (/etc/pam.d/login and
On Thu, Nov 08, 2007 at 10:06:35AM -, lcars wrote:
Here are the modified pam files, all the others are left untouched,
Ok, sure; in that case the sufficient + sufficient is not the complete
stack, and the return value is controlled by the presence of other PAM
modules listed in the
Well I am telling you that sufficient + sufficient for pam_ldap and pam_unix in
common-auth leads to any user being able to log in with blank password. So
something is not behaving properly here. Your assumption re sufficient +
sufficient (which I though too it was right) is incorrect, I
On Wed, Nov 07, 2007 at 09:46:50AM -, lcars wrote:
Well I am telling you that sufficient + sufficient for pam_ldap and
pam_unix in common-auth leads to any user being able to log in with blank
password. So something is not behaving properly here. Your assumption re
sufficient + sufficient
the default is always to fail if no module succeds, that's not true.
Without a pam_deny directive listing two modules as 'sufficient' will
fallback to successful authentication, that's why I opened this bug in the
first place.
Well, no; if the entirety of your stack is sufficient modules,
Thank you for taking the time to file this report and help to improve
the Ubuntu system.
Using pam_deny in the PAM config is cargo-cultism. Neither is it
required for setting the default stack behavior (the default is always
to fail if no module succeeds), nor is including it sufficient to
the default is always to fail if no module succeds, that's not true.
Without a pam_deny directive listing two modules as 'sufficient' will
fallback to successful authentication, that's why I opened this bug in
the first place.
Try using ldap conf and setting in auth/password sufficient for both
For the sake of clarity, sufficient + sufficient leads to the problem.
While sufficient + required doesn't (which is the actual configuration
in shipped files). But it's an easy mistake that lots of people do,
hence why pam_deny might save the day and help the users.
--
pam configuration could
Re-opening so that you can evaluate my last comment, I can provide some
example pam confs if you like to prove that there's no safe defaults at
the moment and the only bit that enforces a safe fallback is using
'required' in one of the modules.
If you still think this change shall not be made
12 matches
Mail list logo
