Hi Petter,
On 05/05/2014 10:44 AM, Petter Reinholdtsen wrote:
I am not sure that the configuration should be enabled by default
because in this case it will affect every pam service which use
/etc/pam.d/common-auth, like su, sudo, login and so on.
I expect packages I install to work out of the box, unless some
configuration is required to get it working. I believe it is the
Debian way, and our uses expect it. If they do not want to use
libpam-abl, they should just uninstall it. And in this case, I was
wondering if we should enable this pam module in the Freedombox
project and here we would like to set up the machine at installation
time without having to edit configuration files.
I agree with this approach. After all, it is the user's decision to
install or remove a package.
Btw, why is libpam-abl operating on local services too? Why not only
trigger for remote login?
pam-auth-update operates on /etc/pam.d/common-* files, in case with
libpam-abl it is
/etc/pam.d/common-auth file.
And common-auth is included in many other profiles in /etc/pam.d/
Typically pam_abl.so is added to the auth stack as a required module
just before whatever modules actually perform authentication.
for this reason I've set Priority in /usr/share/pam-configs/abl to 1024
points, even if it doesn't fit nicely the specification [0].
Actually it is not that bad feature to block bruteforce for the local
services I think,
just users should be aware of it.
Can you test the package ? The binary package will not work on
wheezy, but should be ok for testing.
I'll try to find time to test it.
That would be great.
Best,
Alex
[0] https://wiki.ubuntu.com/PAMConfigFrameworkSpec#Design
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
