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

Eli Schwartz eschwartz at archlinux.org
Wed Feb 20 17:10:48 UTC 2019


On 2/20/19 11:29 AM, Ralph Corderoy wrote:
> Hi David,
> 
>> My question is what do I put in /etc/pam.d/vsftpd?
> 
> It seems flawed that individual users, like you and me, are having to
> concoct /etc/pam.d files due to packages not providing them and the
> working default having been removed by a pambase upgrade.  This is
> because we're not knowledgable in PAM and it's easy to create a file
> that allows authentication again but is too permissive.  The end result
> is worse than the working default that pambase removed, presuambly
> removed with improving security in mind.

How would it be "worse", precisely? If the advice is to use a policy
that matches the old "other" policy, then how exactly was security
*reduced*?

> From a QA point of view, shouldn't the old pambase default be put back,
> packages that lack their own /etc/pam.d identified and fixed with
> well-considered authentication, and then the pambase change re-released?

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.

Given the rationale for proposing the change was specifically that such
applications "should" be breaking, because they are wrong and need to
ship a policy due to the lack of an explicit policy being a security
concern, it seems rational to argue that it's better for applications to
break in a manner that warns the user and encourages applications that
are doing the wrong thing to begin with, than continue to paper over the
cracks.

But perhaps you have an answer to the package maintainer's comment:
> I don't know of a good way to determine when "other" is used on my
> system, or in aggregate across a larger number of users to avoid
> problems.

-- 
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/20190220/1935ccc0/attachment.sig>


More information about the arch-general mailing list