[arch-general] pambase - creating needed files for apps with normal user auth - pam_unix.so?

[Eli Schwartz]

On 2/22/19 11:49 PM, David C. Rankin wrote:
> On 02/20/2019 11:10 AM, Eli Schwartz via arch-general wrote:
>> From a QA point of view, if no one found the packages which lack a
>> policy in the several years the pambase ticket was open for, then
>> putting a permissive policy back in place means we will, once again,
>> never find these packages.
> 
> Well, that is somewhat a "straw-man" argument. I is rather difficult to find
> packages which lack a policy when (1) you don't know there is a pambase bug
> open or (2) that a default change to pambase is coming until things start
> breaking. The last note on the homepage is for "ibutf8proc>=2.1.1-3 update
> requires manual intervention" from July 2018.
> 
> I don't mind learning PAM, but it is horribly inconvenient when you have
> time-critical documents to scan for the Court that suddenly won't make it from
> the copier to the server any more.
> 
> Somewhere there is a fine line between what a normally adept user should be
> expected to know and topics that developers are working with. That was made
> clear when public posts to the arch-dev list were suspended.
> 
> Knowing that there are likely a number of packages that still need a policy,
> like vsftpd, is there somewhere we should keep a list so that packages can
> include the policy and an install script? Or should we just mail the
> maintainer directly? Doesn't seem like a bug is warranted, but I'll defer to
> whatever the consensus is.

For vsftpd, see https://bugs.archlinux.org/task/61746

If a package needs a pam.d policy and does not have one, this is of
course a bug -- please check the bugtracker to see if one exists, and if
not, submit one.

My suggestion would generally be to submit or subscribe to a bug report,
and then (in order of preferred to least preferred):

- apply any workaround or installation of an upstream policy mentioned
  in the bug report
- use the contents of the old pam.d/other as the PAM policy for the
  currently broken package
- modify your own pam.d/other policy to revert back to the former
  insecure defaults, with a note to restore the stock version as soon as
  you're notified that the bug has been fixed

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20190223/b47b8f92/attachment.sig>