1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269
|
.\" Copyright (c) 1993 Michael Haardt (michael@cantor.informatik.rwth-aachen.de), Fri Apr 2 11:32:09 MET DST 1993
.\"
.\" This is free documentation; you can redistribute it and/or
.\" modify it under the terms of the GNU General Public License as
.\" published by the Free Software Foundation; either version 2 of
.\" the License, or (at your option) any later version.
.\"
.\" The GNU General Public License's references to "object code"
.\" and "executables" are to be interpreted as the output of any
.\" document formatting or typesetting system, including
.\" intermediate and printed output.
.\"
.\" This manual is distributed in the hope that it will be useful,
.\" but WITHOUT ANY WARRANTY; without even the implied warranty of
.\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
.\" GNU General Public License for more details.
.\"
.\" You should have received a copy of the GNU General Public
.\" License along with this manual; if not, write to the Free
.\" Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139,
.\" USA.
.\"
.\" Modified Sun Jul 25 10:44:50 1993 by Rik Faith (faith@cs.unc.edu)
.\" Modified Thu Feb 26 16:08:49 MET 1995 by Michael Haardt
.\" Modified Sat Jul 20 14:39:03 MET DST 1996 by Michael Haardt
.\" Modified Sat Aug 10 15:26:25 MET DST 1996 by Michael Haardt
.\" 2002-09-24 Daniel Kobras <kobras@linux.de>
.\" * Typo fixes.
.\" * Update example struct to glibc 2.2.5.
.\"
.TH UTMP 5 "24. September 2002" "Linux" "Dateiformate"
.SH BEZEICHNUNG
utmp, wtmp \- login Einträge
.SH ÜBERSICHT
.B "#include <utmp.h>"
.SH BESCHREIBUNG
Die
.I utmp
Datei gibt Auskunft darüber, wer das System im Moment benutzt. Da nicht
alle Programme
.I utmp
benutzen, kann es jedoch noch mehr Benutzer im System geben.
.B Warnung:
.I utmp
darf nicht allgemein schreibbar sein, weil viele Systemprogramme von
der Korrektheit dieser Datei abhängig sind. Falls Sie
.I utmp
für jeden schreibbar lassen, riskieren Sie falsche Einträge in
Systemlogdateien und Modifikationen von Systemdateien.
Die Datei besteht aus einer Sequenz von Einträgen der Struktur
.IR utmp ,
die über die Include-Datei deklariert wird. Das Format von
.I utmp
ist nicht strikt festgelegt, sondern hängt ab von der Version der
verwendeten libc. Das folgende Beispiel ist glibc 2.2.5 entnommen:
.RS
.nf
.sp
.ta 3i
#define UT_UNKNOWN 0
#define RUN_LVL 1
#define BOOT_TIME 2
#define NEW_TIME 3
#define OLD_TIME 4
#define INIT_PROCESS 5
#define LOGIN_PROCESS 6
#define USER_PROCESS 7
#define DEAD_PROCESS 8
#define ACCOUNTING 9
#define UT_LINESIZE 32
#define UT_NAMESIZE 32
#define UT_HOSTSIZE 256
struct exit_status {
short int e_termination; /* Abbruchstatus des Prozesses. */
short int e_exit; /* Rückgabestatus des Prozesses. */
};
struct utmp {
short int ut_type; /* Typ des Eintrags */
pid_t ut_pid; /* Kennung des Anmeldeprozesses */
char ut_line[UT_LINESIZE]; /* Gerätename \- "/dev/" */
char ut_id[4]; /* init id or abgek. Leitungsname */
char ut_user[UT_NAMESIZE]; /* Benutzer login-Name */
char ut_host[UT_HOSTSIZE]; /* Rechner-Name bei remote login */
struct exit_status ut_exit; /* Rückgabestatus eines Prozesses, der
als DEAD_PROCESS markiert ist. */
long int ut_session; /* Sessionkennung, benutzt, um mehrere
Fenster zu unterscheiden. */
struct timeval ut_tv; /* Zeit, zu der der Eintrag erstellt
wurde. */
int32_t ut_addr_v6[4]; /* Internetadresse des Ursprungsrechners
der Login-Verbindung. */
char __unused[20]; /* Unbenutzt, reserviert für spätere
Verwendung. */
};
.sp
.fi
.RE
Diese Struktur enthält den Namen der Gerätedatei für das Terminal des
Benutzers, seinen Login-Namen und den Zeitpunkt im Format von
.BR time (2),
an dem er sich eingeloggt hat. Zeichenketten sind mit \fB'\e0'\fP
terminiert, falls sie kürzer als das Feld sind, das sie enthält.
Die ersten Einträge, die je erstellt werden, entstehen durch
.BR init (8),
der
.BR inittab (5)
verarbeitet. Bevor ein solcher Eintrag verarbeitet wird, räumt
.BR init (8)
.I utmp
auf, indem bei jedem Eintrag dessen
.BR ut_type " nicht"
.BR DEAD_PROCESS " oder " RUN_LVL
ist und für den kein Prozess mit der PID
.BR ut_pid " existiert,"
.BR ut_type " auf " DEAD_PROCESS
gesetzt wird und
.BR ut_user ","
.BR ut_host " und "
.BR ut_time
mit Null-Bytes gefüllt werden. Falls kein leerer Eintrag mit der benötigten
.B ut_id
gefunden wird, erstellt init einen. Dabei wird
.B ut_id
von inittab übernommen,
.BR ut_pid " und " ut_time
auf die aktuellen Werte und
.BR ut_type " auf " INIT_PROCESS " gesetzt wird."
.BR getty (8)
findet den Eintrag mittels der PID, ändert
.BR ut_type " zu " LOGIN_PROCESS ", ändert " ut_time ", setzt " ut_line
und wartet darauf, dass eine Verbindung hergestellt wird. Nachdem
.BR login (8)
einen Benutzer authentifizieren konnte, ändert es
.BR ut_type " zu " USER_PROCESS ", ändert " ut_time " und setzt "
.BR ut_host " und " ut_addr ". Je nach "
.BR getty (8)
und
.BR login (8)
könnten Einträge auch mittels
.BR ut_line " anstatt der vorzuziehenden " ut_pid " gefunden werden."
Wenn
.BR init (8)
feststellt, dass ein Prozess beendet wurde, lokalisiert es den
entsprechenden utmp Eintrag mittels
.BR ut_pid ", setzt"
.BR ut_type " auf " DEAD_PROCESS " und füllt "
.BR ut_user ,
.BR ut_host " und " ut_time " mit Null-Bytes."
.BR xterm (1)
und andere Terminal-Emulatoren erstellen direkt einen
.BR USER_PROCESS \-
Eintrag und erzeugen die
.BR ut_id " entweder durch die letzten beiden Zeichen von"
.BI /dev/ttyp %c
oder durch
.BI p %d
bei
.BI /dev/pts/ %d.
Falls sie einen
.BR DEAD_PROCESS \-
Eintrag für diese ID finden, wird er wieder benutzt, ansonsten wird ein
neuer Eintrag erstellt. Falls möglich, markieren sie vor Beendigung den
Eintrag als
.BR DEAD_PROCESS " und es wird geraten, dass sie "
.BR ut_line ", " ut_time ", " ut_user " und " ut_host " mit Nullen füllen."
.BR xdm (8)
sollte keinen utmp-Eintrag erstellen, weil es kein
zugeordnetes Terminal gibt. Falls es trotzdem gemacht wird, werden
.\" FIXME testen, dass es wirklich cannot heißt, nicht can not
Fehlermeldungen wie finger: cannot stat /dev/machine.dom die Folge
sein. Es sollte jedoch ein wtmp Eintrag erzeugt werden, genau wie es
auch bei
.BR ftpd (8)
geschieht.
.BR telnetd (8)
erzeugt einen
.BR LOGIN_PROCESS "\-Eintrag und lässt"
.BR login (8)
den Rest erledigen. Nachdem die telnet-Sitzung beendet ist, markiert
.BR telnetd (8)
den
.IR utmp \-
Eintrag in der oben
beschriebenen Art und Weise.
Die
.I wtmp
Datei zeichnet alle An- und Abmeldungen im System auf. Das Format gleicht
.BR utmp ,
mit der Ausnahme, dass ein leerer Benutzername eine Abmeldung vom angegebenen
Terminal anzeigt. Weiterhin bedeutet die Terminalleitung \fB"~"\fP mit dem
Benutzernamens \fB"shutdown"\fP oder \fB"reboot"\fP ein Herunterfahren bzw.
den Neustart des Systems und das Paar der Terminalleitungen
\fB"|"\fP/\fB"}"\fP zeichnet die alte/neue Systemzeit auf, wenn diese durch
.BR date (1)
geändert wird.
.I wtmp
wird durch
.BR login (1),
.BR init (8)
und
.BR getty (1)
verwaltet. Keins dieser Programme erstellt die Datei, so dass, falls sie
gelöscht wird, keine Aufzeichnungen mehr gemacht werden.
.SH DATEIEN
.I /var/run/utmp
.br
.I /var/log/wtmp
.SH "KONFORM ZU"
Linux utmp Einträge sind weder zu v7/BSD noch zu SYSV konform: Sie sind
eine Vereinigung von beidem. v7/BSD hat weniger Felder, vor allem fehlt
.BR ut_type ,
was ursprüngliche v7/BSD-ähnliche Programme veranlaßt, tote und
login-Einträge anzuzeigen. Weiterhin gibt es keine Konfigurationsdatei,
die jeder Session eine Eintragsnummer zuordnet. Dies wird in BSD gemacht,
weil dort
.BR ut_id " fehlt. In Linux (wie in SYSV), wird das "
.B ut_id
Feld eines Eintrags nach dem initialen Setzen nie wieder geändert,
wodurch diese Eintragnummer ohne jede Konfigurationsdatei reserviert wird.
.B ut_id
zu löschen führt zu Race-Conditions und resultiert in beschädigten utmp
Einträgen und potenziellen Sicherheitslöchern. Die SYSV-Semantik verlangt
nicht, die oben angegebenen Felder mit Null-Bytes zu löschen, aber es
erlaubt viele Programme zu benutzen, die die BSD-Semantik benutzen und
utmp nicht verändern. Wie beschrieben, benutzt Linux die BSD-Konventionen
für Leitungsnamen. SYSV benutzt nur das Typ-Feld um solche Einträge zu
markieren und zeichnet Meldungen wie \fB"new time"\fP im Leitungs-Feld
auf. SYSV hat ein Feld mehr, um den Exit-Status von beendeten Prozessen
aufzuzeichnen.
.B UT_UNKNOWN
scheint eine Linux Erfindung zu sein. In Linux gibt es keinen
.B ACCOUNTING
Typ. SYSV hat kein
.BR ut_host " oder " ut_addr
Feld. Anders als bei verschiedenen anderen Systemen, wo utmp
Aufzeichnungen durch Löschen der Datei abgeschaltet werden können, muss
utmp bei Linux immer vorhanden sein. Falls
.BR who (1)
verboten werden soll, dann kann man utmp einfach
nicht allgemein lesbar machen.
.SH EINSCHRÄNKUNGEN
Das Dateiformat ist maschinengebunden. Es wird daher empfohlen, dass
es nur auf der Architektur verarbeitet wird, auf der es erstellt wurde.
.SH FEHLER
Ein Großteil der obigen Beschreibung basiert auf der libc5. Aktuelle
Versionen könnten inzwischen ein anderes Verfahren verwenden.
.SH "SIEHE AUCH"
.BR ac (1),
.BR date (1),
.BR last (1),
.BR login (1),
.BR who (1),
.BR getutent (3),
.BR updwtmp (3),
.BR init (8).
|