You are not logged in.
What is wrong in the following arguments?
At /etc/pam.d/system-auth,
% 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.
powerofforreboot.efi (AUR): Utilities to be used from within a UEFI boot manager or shell.
Offline
Legacy from https://github.com/gentoo/pambase
Offline
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?
Last edited by regid (2019-04-23 00:06:17)
powerofforreboot.efi (AUR): Utilities to be used from within a UEFI boot manager or shell.
Offline
My understanding matches yours but it should be raised on the wiki.
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.
Last edited by loqs (2019-04-23 01:10:42)
Offline
What issues are there of the change to /etc/pam.d/other?
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.
powerofforreboot.efi (AUR): Utilities to be used from within a UEFI boot manager or shell.
Offline
Offline
I keep posting to this thread so that information will be a little bit more concentrated at one place. Hopefully, eventually Arch will have the resources to further appraise removing what I think are useless lines.
With my current setting:
% 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
Last edited by regid (2019-04-23 18:13:23)
powerofforreboot.efi (AUR): Utilities to be used from within a UEFI boot manager or shell.
Offline
At his post from Tuesday, 23-Apr-2019 at 02:10:11, loqs mentioned that https://lwn.net/Articles/688235/ also touches on pam_permit.
Rereading detailed analyses linked at the beginning by the mentioned lwn article, isn't there a missing detail in the PAM documentation?
On one hand, there is the quote already mentioned at the 1st post of this thread:
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?
Last edited by regid (2019-04-25 08:37:01)
powerofforreboot.efi (AUR): Utilities to be used from within a UEFI boot manager or shell.
Offline
Wouldn't optional modules is what should be looked at?
% 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.
Last edited by regid (2019-04-25 08:32:53)
powerofforreboot.efi (AUR): Utilities to be used from within a UEFI boot manager or shell.
Offline
I think Arch has some useless lines in its default PAM configuration. By useless I refer to lines that has no effect on the system behavior. The common saying is to not fix something which is not broken. But, in this case, those lines create confusion. And confusion here leads to a lesser degree of trust. Which is sort of breakage. Also, some might do wrong things because they are confused.
The lines suspected at being useless I want to refer to are those of type optional. PAM ignores the output of optional modules unless they are the only modules for their service+type. But it runs them. Some of these modules have side effects. So the question arise which optional modules have side effect. Those that don’t, and they are also not the only modules for both their service and type, form useless lines.
I think all the PAM configuration files I have installed at the time of this writing are from pambase-20190105.1-1, shadow-4.6-2 and pam-1.3.1-1.
% 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
Last edited by regid (2019-04-25 08:31:09)
powerofforreboot.efi (AUR): Utilities to be used from within a UEFI boot manager or shell.
Offline
maybe we should open a bug to remove pam_permit from the default files in pambase
Offline