QuoteVorbereitung zum Ersetzen von login 1:4.1.4.2+svn3283-3 (durch .../login_1%3a4.1.5-1_amd64.deb) ...
Ersatz für login wird entpackt ...
Trigger für man-db werden verarbeitet ...
login (1:4.1.5-1) wird eingerichtet ...
Neue Version der Konfigurationsdatei /etc/securetty wird installiert ...
Konfigurationsdatei »/etc/login.defs«
==> Modifiziert (von Ihnen oder von einem Skript) seit der Installation.
==> Paketverteiler hat eine aktualisierte Version herausgegeben.
Wie möchten Sie vorgehen? Ihre Wahlmöglichkeiten sind:
Y oder I : Die Version des Paket-Betreuers installieren
N oder O : Die momentan installierte Version beibehalten
D : Die Unterschiede zwischen den Versionen anzeigen
Z : Eine Shell starten, um die Situation zu begutachten
Der Standardweg ist das Beibehalten der momentanen Version.
*** login.defs (Y/I/N/O/D/Z) [Vorgabe=N] ?
nun, wer hat das modifiziert? Ich durch das anlegen eines users bei der erstinstallation? Sonst wüßte ich nicht. Gibt es grund zur nervosität?
Vorgabe=N
Wo ist das Problem?
Und gucke dir die Datei doch einfach an. Da ist also rein gar nicht, worum du dich kümmern musst. Bei N bleibt ja trotzdem alles beim alten.
# /etc/securetty: list of terminals on which root is allowed to login.
# See securetty(5) and login(1).
console
# Standard serial ports
ttyS0
ttyS1
ttyS2
ttyS3
ttyS4
ttyS5
# USB dongles
ttyUSB0
ttyUSB1
ttyUSB2
# PowerMac
ttyPZ0
ttyPZ1
ttyPZ2
ttyPZ3
# Embedded MPC platforms
ttyPSC0
ttyPSC1
ttyPSC2
ttyPSC3
ttyPSC4
ttyPSC5
# PA-RISC mux ports
ttyB0
ttyB1
# Standard hypervisor virtual console
hvc0
# Oldstyle Xen console
xvc0
# Standard consoles
tty1
tty2
tty3
tty4
tty5
tty6
# Local X displays (allows empty passwords with pam_unix's nullok_secure)
:0
:0.0
:0.1
:1
:1.0
:1.1
:2
:2.0
:2.1
:3
:3.0
:3.1
# Embedded Freescale i.MX ports
ttymxc0
ttymxc1
ttymxc2
ttymxc3
ttymxc4
ttymxc5
# Embedded Renesas SuperH ports
ttySC0
ttySC1
ttySC2
ttySC3
ttySC4
ttySC5
dass mir dies sicherheitsrelevant erscheint und ich mich frage wer das modifiziert hat? Ich war das sicher nicht (direkt).
Der Paketverwalter natürlich. Mit jedem Update ändern sich Pakete und die (oder einige) dazugehörigen Dateien.
Ich habe seit dem heutigen DU folgenden Fehler wenn ich in der Konsole sux eingebe:
bash: cannot set terminal process group (-1) Inappropriate Ioctl() for device
bash: no job control in this shell
Ich habe nicht viel gefunden - jemand hat aber ein Debian bug angemeldet:
QuoteBug# 659832
sux bash prints ioctl warnings
hat noch jemand diesen Fehler - ist dies ein bug von login?
gruss
Kwoby
@kwoby:
Zu den Fragen: Ja, ist ein Bug, deswegen gibt es ja auch eine Bugnummer.
Warum kaperst du diesen Thread.
Ich möchten den thread nicht kappern... aber ich glaube meine Bemerkung hat mit dem neuen "login" etwas zu tun und dass der sux Fehler ev. mit dem neuen Login zu tun hat.
Wenn das der Fall ist und andere nach dem "neuen" Login denselben Fehler haben könnten man ev wissen, dass man den "neuen" login nicht laden muss oder ev den alten wieder laden...
gruss
Kwoby
Den Fehler werden alle haben. Gegen login gabs mindestens 8 bugreports seit 12.2., die alle schon geschlossen sind. der gegen sux ist noch offen. Das changelog zu login erklärt, was da passiert ist:
Quotesu: Fix possible tty hijacking by dropping the controlling terminal when
executing a command (CVE-2005-4890). Closes: #628843
Kann sein, dass sux dabei vergessen wurde.
greetz
devil