Le 04/03/2016 18:11, Raphael Hertzog a écrit :
Do you care to explain why you would disable that line?
You will likely break many other scripts in Debian and I don't see the
point of stopping installation for this specific case.
Cheers,
Hi Raphael!
Thanks for your answer,
In that specific case, the installation is broken because su waits in an
infinite loop that root can only break by a SIGKILL signal. After
the kill, some lock and status files prevent dpkg to remove
debian-security-support. After reboot, the package can be removed well
and the sysadmin can relax stating that nothing in APT is broken.
Here is my motivation not to allow root to invoke su without prompting
for password by default:
Debian 'out of box' is not well configured for data privacy in a
multi-user environment (see the overliberal default umask 0022).
So, as I had to review the global system specifications for my needs,
I rely on some simple fundamental rules.
One of theses rules is Occam's razor that KISS principle is derived from:
"Plurality must never be posited without necessity". And until I went to
install the package debian-security-support, I did'nt saw any necessity
for allowing root to invoke su without prompting for password.
Let me explain further with an example:
Let's say ulysses has just installed debian 7 on the family
computer, enforced the per user file insulation (UMASK 007 in
/etc/login.defs, DIR_MODE=0770 in /etc/adduser.conf) and created the
users penelope and telemachus.
Is it a necessity that ulysses could login (and spoof) as penelope and
telemachus without knowing their passwords, even if ulysses can browse
their files? I don't think so and even the program runas.exe
Microsoft Windows forbid that behaviour by default.
Moreover in that example, penelope and telemachus could never be aware
that ulysses spoof their identity for years:
telemachus@debian7:~$ cat /var/log/auth.log
cat: /var/log/auth.log: Permission denied
That's why I would prefer this login capability for root was not enabled
in /etc/pam.d/su by default.
To come back to the main subject, I'm not aware of other package that
configures using su, but I understand and agree to change my practice to
conform with the good work that debian devs have done.
What I say is just: maybe one day, another person will try to install
debian-security-support after he has customized /etc/pam.d/su.
In this case, a message via syslog or frontend provided by a preinst
script could help when su make dpkg to freeze, especialy if that person
have not enough skills to debug and understand what
/var/lib/dpkg/info/debian-security-support.postinst do.
Best regards,
Mederic.