| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| pam_unix_dont_trust_chkpwd_caller.patch | pam_unix_dont_trust_chkpwd_caller Dropping suid bits is not enough to let us trust the caller; the unix_chkpwd helper could be sgid shadow instead of suid root, as it is in Debian and Ubuntu by default. Drop any sgid bits as well. Michael Spang <mspang@csclub.uwaterloo.ca> Upstream status: to be submitted |
Sam Hartman <hartmans@debian.org> | no | 2023-09-11 | ||
| make_documentation_reproducible.patch | Make documentation reproducible Add LC_ALL=C.UTF-8 to w3m to avoid changes in the output when build the documentation with different locales. |
"jumapico@gmail.com" <jumapico@gmail.com> | no | 2019-01-06 | ||
| 0003-pam_unix-obscure-checks.patch | pam_unix: obscure checks * Bring in the obscure checks that used to live in shadow so we can still support them * Set default minimum password length to 6 |
Sam Hartman <hartmans@debian.org> | no | 2023-09-11 | ||
| 022_pam_unix_group_time_miscfixes | handle the case of flags being empty or only PAM_SILENT, which is documented in other PAM implementations as meaning PAM_ESTABLISH_CRED: http://publib.boulder.ibm.com/infocenter/aix/v6r1/index.jsp?topic=%2Fcom.ibm.aix.basetechref%2Fdoc%2Fbasetrf1%2Fpam_setcred.htm |
Sam Hartman <hartmans@debian.org> | no | 2023-09-11 | ||
| 026_pam_unix_passwd_unknown_user | distinguish between password manipulation failure and missing user. | Martin Schwenke <martin@meltin.net> | no | 2023-09-11 | ||
| 031_pam_include | _pam_include Patch to implement an @include directive for use in pam.d config files. Upstream status: not yet submitted |
Sam Hartman <hartmans@debian.org> | no | 2023-09-11 | ||
| 036_pam_wheel_getlogin_considered_harmful | _pam_wheel_getlogin_considered_harmful Patch for Debian bug #163787 et al Always use the process uid, not getlogin(), to identify an applicant in pam_wheel; utmp may be wrong or may have no entry at all in the case of an xterm Upstream status: submitted in <20070901175405.GA26092@dario.dodds.net> |
Sam Hartman <hartmans@debian.org> | no | 2023-09-11 | ||
| 027_pam_limits_better_init_allow_explicit_root | Allow explicit limits for root and reset limits on each session When crossing session boundaries (such as when su'ing from one user to another), if the target account has no limit specified in limits.conf we want to use the default, not the current value configured for the source account. If /proc/1/limits is unavailable, fall back to a set of hard-coded values that shadow the currently known defaults on Linux. Also, don't apply wildcard limits to the root account; only apply limits to root that reference root by name. =================================================================== |
Peter Paluch <peterp@frcatel.fri.utc.sk> | no | debian | 2023-09-11 | |
| pam-limits-nofile-fd-setsize-cap | pam_limits: cap the default soft nofile limit read from pid 1 to FD_SETSIZE Cap the default soft nofile limit read from pid 1 to FD_SETSIZE since larger values can cause problems with fd_set overflow and systemd sets itself higher. See: https://lists.ubuntu.com/archives/ubuntu-devel/2010-September/031446.html http://www.outflux.net/blog/archives/2014/06/13/5-year-old-glibc-select-weakness-fixed/ https://sourceware.org/bugzilla/show_bug.cgi?id=10352 https://github.com/systemd/systemd/commit/4096d6f5879aef73e20dd7b62a01f447629945b0 pam_limits reads the default limits from /proc/1/limits. Previously, using upstart, this resulted in a 1024 nofile soft limit on Ubuntu systems by default. Using systemd, this results in a limit of 65536 instead. This is not the intention of systemd upstream. See systemd commit 4096d6f for an explanation of systemd's behaviour. If we want to make such a change to the default distribution soft limit in PAM, we should do it deliberately and carefully, not accidentally. A change should consider what uses select(2) and might inadvertently (and incorrectly) assume that file descriptors will always fit into an fd_set, what vulnerabilities or crashes the change could consequently create, and whether the protection now present with FORTIFY_SOURCE is suitably enabled in all relevant builds. So this keeps the soft limit at 1024 for now. The hard limit will rise to 65536 along with systemd. Anything that knows that it will not be buggy with respect to fd_set and FD_SETSIZE, such as by using poll(2) or epoll(7) instead of select(2), can always raise the soft limit itself without issue. 20:54 <rbasak> slangasek: [...] I'm also not sure how to go about upstreaming this as pam_limits seems to be heavily patched already. |
Robie Basak <robie.basak@ubuntu.com> | no | 2015-04-22 | ||
| 032_pam_limits_EPERM_NOT_FATAL | _pam_limits_EPERM_NOT_FATAL setrlimit will sometimes return EPERM for example if you try to increase the number of open files too much. This is not something we want to consider fatal. This also happens if you use non-root and try to decrease a limit. Running PAM as non-root is not so great. Upstream status: submitted in <20070830171918.GB30563@dario.dodds.net> |
Sam Hartman <hartmans@debian.org> | no | 2023-09-11 | ||
| 008_modules_pam_limits_chroot | _modules_pam_limits_chroot =================================================================== |
Sam Hartman <hartmans@debian.org> | no | 2023-09-11 | ||
| 040_pam_limits_log_failure | _pam_limits_log_failure Patch for Debian bug #180310 Generate some (low-severity) log information whenever setrlimit() fails, for debugging purposes. Upstream status: submitted in <20070830171918.GB30563@dario.dodds.net> |
Sam Hartman <hartmans@debian.org> | no | 2023-09-11 | ||
| 045_pam_dispatch_jump_is_ignore | _pam_dispatch_jump_is_ignore Previously jumps were treated as PAM_IGNORE in the freezing part of the chain and PAM_OK (aka required) in the frozen part of the chain. No one on pam-list was able to explain this behavior, so I changed it to be consistent. |
Sam Hartman <hartmans@debian.org> | no | 2023-09-11 | ||
| hurd_no_setfsuid | hurd_no_setfsuid On systems without setfsuid(), use setreuid() instead. Upstream status: to be forwarded, now that pam_modutil_{drop,regain}_priv are implemented |
Sam Hartman <hartmans@debian.org> | no | 2023-09-11 | ||
| PAM-manpage-section | PAM-manpage-section Patch to put the PAM manpage in section 7 (general topics) instead of 8 (system administration commands) Upstream status: maybe provide a backwards-compatibility link first? |
Sam Hartman <hartmans@debian.org> | no | 2023-09-11 | ||
| update-motd | update-motd Provide a more dynamic MOTD, based on the short-lived update-motd project. |
Sam Hartman <hartmans@debian.org> | no | 2019-02-12 | ||
| lib_security_multiarch_compat | lib_security_multiarch_compat Unqualified module paths should always be looked up in *both* the default module dir, *and* the ISA dir. That's what paths are for. This lets us have a soft transition to multiarch for modules without having to rewrite /etc/pam.d/ files or add ugly symlinks. Upstream status: not ready to be committed - this needs tweaked, we're currently abusing the existing variables and inverting their meaning in order to get everything installed where we want it and get absolute paths the way we want them. |
Sam Hartman <hartmans@debian.org> | no | 2023-09-11 | ||
| no_PATH_MAX_on_hurd | define PATH_MAX for compatibility when it's not already set Some platforms, such as the Hurd, don't set PATH_MAX. Set a reasonable default value in this case. |
Steve Langasek <vorlon@debian.org> | no | debian | 2023-09-11 | |
| fix-autoreconf.patch | fix-autoreconf.patch Do not override user variables in Makefile.am, see the "Flag Variables Ordering" section of the automake manual. |
Andreas Henriksson <andreas@fatal.se> | no | 2018-11-08 | ||
| nullok_secure-compat.patch | Support nullok_secure as a deprecated alias for nullok | Steve Langasek <vorlon@debian.org> | no | 2020-08-11 | ||
| pam_mkhomedir_stat_before_opendir | pam_mkhomedir_stat_before_opendir =================================================================== |
Sam Hartman <hartmans@debian.org> | no | 2023-09-11 | ||
| pam_namespace_o_directory | From: Matthias Gerstner <matthias.gerstner@suse.de> Date: Wed, 27 Dec 2023 14:01:59 +0100 Subject: pam_namespace: protect_dir(): use O_DIRECTORY to prevent local DoS situations Origin: https://github.com/linux-pam/linux-pam/commit/031bb5a5d0d950253b68138b498dc93be69a64cb Bug-Debian: https://bugs.debian.org/1061097 Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2024-22365 Without O_DIRECTORY the path crawling logic is subject to e.g. FIFOs being placed in user controlled directories, causing the PAM module to block indefinitely during `openat()`. Pass O_DIRECTORY to cause the `openat()` to fail if the path does not refer to a directory. With this the check whether the final path element is a directory becomes unnecessary, drop it. |
Sam Hartman <hartmans@debian.org> | no | 2024-02-02 | ||
| ftbfs-implicit-function-declaration | Fix FTBFS when built with -Werror=implicit-function-declaration | Sam Hartman <hartmans@debian.org> | no | 2024-02-29 |