% grep -r optional /etc/pam.d | sed -n 's/.*\(pam_.*.so\).*/\1/p' | sort | uniq
pam_keyinit.so
pam_loginuid.so
pam_mail.so
pam_motd.so
pam_permit.so
pam_systemd.so
There are 6 modules, at
% grep -r optional /etc/pam.d | wc -l
13
13 lines.
By their man pages, the only module in that list that doesn’t have side effect is pam_permit.so. There are
% grep -r 'optional.*pam_permit.so' /etc/pam.d
/etc/pam.d/system-services:session optional pam_permit.so
/etc/pam.d/system-auth:auth optional pam_permit.so
/etc/pam.d/system-auth:account optional pam_permit.so
/etc/pam.d/system-auth:password optional pam_permit.so
/etc/pam.d/system-auth:session optional pam_permit.so
5 lines that run optional pam_permit.so. Non of these lines make the module the only service+type module. Therefore, there are 5 useless lines. All of them are from pambase.
For completeness, my suggestion at an earlier post was
::::::::::::::
/etc/pam.d/system-auth
::::::::::::::
#%PAM-1.0
# Commented in useless pam_permit lines as per
# https://bbs.archlinux.org/viewtopic.php?id=245892.
auth required pam_unix.so try_first_pass nullok
#auth optional pam_permit.so
auth required pam_env.so
account required pam_unix.so
#account optional pam_permit.so
account required pam_time.so
password required pam_unix.so try_first_pass nullok sha51
2 shadow
#password optional pam_permit.so
session required pam_limits.so
session required pam_unix.so
#session optional pam_permit.so
::::::::::::::
/etc/pam.d/system-services
::::::::::::::
#%PAM-1.0
auth sufficient pam_permit.so
account include system-auth
session optional pam_loginuid.so
session required pam_limits.so
session required pam_unix.so
# Commented in useless pam_permit line as per
# https://bbs.archlinux.org/viewtopic.php?id=245892.
#session optional pam_permit.so
session required pam_env.so
% grep -r optional /etc/pam.d
/etc/pam.d/system-services:session optional pam_loginuid.so
/etc/pam.d/system-services:#session optional pam_permit.so
/etc/pam.d/system-auth:#auth optional pam_permit.so
/etc/pam.d/system-auth:#account optional pam_permit.so
/etc/pam.d/system-auth:#password optional pam_permit.so
/etc/pam.d/system-auth:#session optional pam_permit.so
/etc/pam.d/system-login:session optional pam_loginuid.so
/etc/pam.d/system-login:session optional pam_keyinit.so force revoke
/etc/pam.d/system-login:session optional pam_motd.so motd=/etc/motd
/etc/pam.d/system-login:session optional pam_mail.so dir=/var/spool/mail standard quiet
/etc/pam.d/system-login:-session optional pam_systemd.so
/etc/pam.d/rlogin:session optional pam_keyinit.so force revoke
/etc/pam.d/rsh:session optional pam_keyinit.so force revoke
Here, /etc/motd is empty, and there is no /etc/motd.d directory. When I wrote something to /etc/motd it was displayed at login. And it wasn't displayed at login when I commented in the pam_motd line at /etc/pam.d/system-login, and kept /etc/motd non empty. Which looks to me consistent with the fact that only the success, or failure, of optional modules are ignored when they are not the only module for a service+type. If I am right so far, optional modules lines are not completely useless when the modules have side effects.
]]>optional
the success or failure of this module is only important if it is the only module in the stack associated with this service+type.
At the other hand, a few lines above that quote, it is stated:
sufficient
if such a module succeeds and no prior required module has failed the PAM framework returns success to the application or to the superior PAM stack immediately without calling any further modules in the stack. A failure of a sufficient module is ignored and processing of the PAM module stack continues unaffected.
Both quotes taken from http://linux-pam.org/Linux-PAM-html/sag … -file.html.
Is it clear what happens if the stack has only sufficient and optional module for some service+type? Will the optional module ignored, since it is not the only module for that service+type, or will pam process it when the sufficient module yield failure? Doesn't the detailed analyses can be interpreted to suggest the usage of the optional module, despite it being optional?
As an alternative, maybe the detailed analyses is wrong at claiming the pam_permit is responsible for allowing undesired login? Examining their configuration
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth sufficient pam_sss.so try_first_pass
auth optional pam_permit.so
, can it be that the pam_permit module was ignored, since it is not the only module for service+type, the sufficient modules ignored because they failed, so the stack was left with the succeeded pam_env module?
]]>% grep -r permit /etc/pam.d
/etc/pam.d/system-services:auth sufficient pam_permit.so
/etc/pam.d/system-services:session optional pam_permit.so
/etc/pam.d/chfn:password required pam_permit.so
/etc/pam.d/chgpasswd:account required pam_permit.so
/etc/pam.d/system-auth:auth optional pam_permit.so
/etc/pam.d/system-auth:account optional pam_permit.so
/etc/pam.d/system-auth:password optional pam_permit.so
/etc/pam.d/system-auth:session optional pam_permit.so
/etc/pam.d/groupdel:password required pam_permit.so
/etc/pam.d/groupmems:account required pam_permit.so
/etc/pam.d/groupadd:password required pam_permit.so
/etc/pam.d/shadow:password required pam_permit.so
/etc/pam.d/groupmod:password required pam_permit.so
/etc/pam.d/chsh:password required pam_permit.so
/etc/pam.d/usermod:password required pam_permit.so
/etc/pam.d/chage:password required pam_permit.so
/etc/pam.d/useradd:password required pam_permit.so
/etc/pam.d/userdel:password required pam_permit.so
The file I have for /etc/pam.d/system-auth, which is Arch current default (blank lines deleted) for that file, is shown at the 1st post of this thread. The file I have for /etc/pam.d/system-services, which is also Arch current default (blank lines deleted) for that file, is:
% cat /etc/pam.d/system-services
#%PAM-1.0
auth sufficient pam_permit.so
account include system-auth
session optional pam_loginuid.so
session required pam_limits.so
session required pam_unix.so
session optional pam_permit.so
session required pam_env.so
Here, the issue is only for the session type. Therefore, for me, there are total of 5 useless lines. It could be that even for me there are more then these 5 lines because I haven't followed all the included paths. But, for now, I will assume there are only 5 lines. To begin with, I will try commenting in the useless lines.
::::::::::::::
/etc/pam.d/system-auth
::::::::::::::
#%PAM-1.0
# Commented in useless pam_permit lines as per
# https://bbs.archlinux.org/viewtopic.php?id=245892.
auth required pam_unix.so try_first_pass nullok
#auth optional pam_permit.so
auth required pam_env.so
account required pam_unix.so
#account optional pam_permit.so
account required pam_time.so
password required pam_unix.so try_first_pass nullok sha51
2 shadow
#password optional pam_permit.so
session required pam_limits.so
session required pam_unix.so
#session optional pam_permit.so
::::::::::::::
/etc/pam.d/system-services
::::::::::::::
#%PAM-1.0
auth sufficient pam_permit.so
account include system-auth
session optional pam_loginuid.so
session required pam_limits.so
session required pam_unix.so
# Commented in useless pam_permit line as per
# https://bbs.archlinux.org/viewtopic.php?id=245892.
#session optional pam_permit.so
session required pam_env.so
The situation here is the opposite to that in the lwn report you mentioned. My suggestion to Arch is to remove an inherently dangerous pam module from the stack.
I have started a discussion at https://wiki.archlinux.org/index.php/Talk:PAM. I have also added an accuracy template at https://wiki.archlinux.org/index.php/PAM#Examples.
]]>Personally I would not change pambase again until all issues from changes to /etc/pam.d/other have been resolved.
PAM is very easy to get wrong https://lwn.net/Articles/688235/ which also touches on pam_permit.
Is it agreed that
- the latter being what pam_permit.so is used for.
at https://wiki.archlinux.org/index.php/PAM#Examples is wrong? I think there is another semi mistake there: blank password is allowed due to nullok.
I observed
session optional pam_permit.so
at line 25 of https://github.com/gentoo/pambase/blob/ … ession.inc. I gave up following all the conditional configurations they have there. I also gave up looking for pam_permit at the other pam types. Should arch remove its pam_permit lines, or at least add comments so that beginners will not wonder if their understanding is lacking?
]]>% cat /etc/pam.d/system-auth
#%PAM-1.0
auth required pam_unix.so try_first_pass nullok
auth optional pam_permit.so
auth required pam_env.so
account required pam_unix.so
account optional pam_permit.so
account required pam_time.so
password required pam_unix.so try_first_pass nullok sha512 shadow
password optional pam_permit.so
session required pam_limits.so
session required pam_unix.so
session optional pam_permit.so
the service is system-auth, and there are 4 types: auth, account, password and session. Therefore, pam_permit.so is not the only module associated with a service+type in that file. Since http://linux-pam.org/Linux-PAM-html/sag … -file.html states
optional
the success or failure of this module is only important if it is the only module in the stack associated with this service+type.
, pam_permit lines at /etc/pam.d/system-auth do nothing.
]]>