On Sat, Mar 5, 2016 at 8:08 AM, Dag-Erling Sm?rgrav <des at des.no>
wrote:> Nico Kadel-Garcia <nkadel at gmail.com> writes:
>> Dag-Erling Sm?rgrav <des at des.no> writes:
>> > It is relatively trivial to write a PAM module to do that.
>> Which will have the relevant configuration overwritten and disabled
>> the next time you run "authconfig" on Red Hat based sysems.
I'm not
>> sure if this occurs with other systems, but tuning PAM is like tuning
>> SELinux: it's a lot of extra work with little return-on-investment,
>> and in this case for a change that will irritate *every single user*
>> and break a number of API's. I can't recommend this approach.
>
> It won't break any APIs, and have you considered that OP might not have
> a choice? That this may be a legal requirement?
>
> DES
As described, it won't break the SSH API per ses. A careless version
could break rsync over SSH and tools that may rely on automatic
connections via SSH keys or shared authentication models such as
Kerberos. However, it's the API for tools that users run locally that
are most likely to break. Scripts that run remote commands
automatically and use "ssh -n" may break. And gods forbid, because it
would be foolish but I've seen it done, scripts that have the password
input and a full set of scripted command line interactions hardcoded
as part of a remote shell interaction, one prevously recorded with the
"script" command, will need to have an extra option added to handle
this "reply yes" requirement. A particular Perl command I just saw
with quite a complex little MySQL interaction leaps to mind and makes
me shudder in horror.
My concern for API's is basically that of an old XKCD cartoon,
https://xkcd.com/1172/ . It's easy to break people's workflows that
you never even realied existed.
As already pointed out, if necessary, this can be done basically in
/etc/profile (depending on the shells supported). That already
resolves the "don't run this on automated remote SSH scripts" to
avoid
breaking non-interactive tools like rsync, and it gets you away from
having to support a binary module that doesn't exist upstream and
which is vulnerable to bog standard upgrade reconfigurations. I've run
into support issues with just such PAM integration, with a senios
sysadmin who wrote his own settings and couldn't be bothered to make
the PAM configuration tool idempotent, so it *kept appending the
required option* every time the configuration tool ran.