Date: Mon, 05 Dec 2016 15:25:24 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [Bug 214540] pam_exec isn't multithreading save Message-ID: <bug-214540-16-1L5pUMdp49@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-214540-16@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214540 --- Comment #2 from Jan Bramkamp <crest@bultmann.eu> --- I found one case where the same issue in the Linux PAM pam_exec module broke vsftpd and vsftpd had to workaround the problem because afaik Linux lacks the required API to avoid this problem completely. I know that pam_exec is a hack and should only be used for testing or after very careful analysis on the other hand the documentation doesn't warn users about the problem and it's a nasty layering violation that blow up into the system administrators face and I don't want to be the poor bastard how has to debug this under time pressure. The PAM policy isn't supposed to inject race conditions into otherwise "working" applications. Pointing to a "non-normative recommendation" won't help users bitten by this problem. My problem with this is that it's a accident waiting to happen and FreeBSD has the APIs to avoid this whole bug class. To make it worse the ones who will run into the problem (system admins) are often incapable of debugging and patching applications complex enough to use pthreads and PAM. -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-214540-16-1L5pUMdp49>