Warum ist auf einigen Systemen max uid / gid 65534 und nicht 65535?

Wenn die maximale UID 65535 ist, gibt es keinen Wert für einen Fehler oder eine unbekannte UID, wenn die UID in einem vorzeichenlosen 16-Bit-Wert gespeichert ist.

Warum 99

Dies ist nicht wirklich ein Maximum. Es ist ein Schwellenwert, bei dem die IDs für "System" -Konten stoppen und die IDs für "echte Personen" -Konten beginnen. Es ist auch ziemlich willkürlich und variabel. Es gibt keinen wirklichen Grund dafür, dass es 99 ist, außer dass 100 eine praktische runde Zahl ist.

Dies ist eine praktische, runde Zahl, die von den verschiedenen Verwaltungstools für Kennwort- und Gruppendatenbanken für eine Plattform vereinbart wird. In der Debian-Version 7 suchen die Tools useraddund beispielsweise nach den Bereichen von UIDs und GIDs, die als "System" und "Benutzer" zählen, und der letztere Bereich ist sowohl für UIDs als auch GIDs 1000 bis 60000.groupadd/etc/login.defs

Warum 65534?

Zum einen, weil es in POSIX-Systemaufrufen zwei weit verbreitete Konventionen gibt:

• Ein Rückgabewert von -1(in den Rückgabetyp umgewandelt) zeigt einen Fehler an, wobei die Fehlernummer aus dem errnoMakro verfügbar ist .
• Ein Eingabewert von -1zeigt "nicht ändern" an.

Dies sind keine universellen Konventionen. Beachten Sie, dass es zum Beispiel keine Möglichkeit gibt, dass ein Fehler vom geteuid()Systemaufruf zurückgegeben wird. (Prozesse haben immer effektive UIDs.) Es gibt also keinen static_cast<uid_t>(-1)Grund zur Sorge. Mindestens eine davon gilt jedoch für UIDs und GIDs. In setreuid()und setregid()ruft das System ein Argument von -1"keine Änderung" auf. Also static_cast<uid_t>(-1)und static_cast<gid_t>(-1)sind nicht richtig als tatsächliche IDs verwendbar.

Zweitens, weil UIDs und GIDs unter Linux früher 16-Bit waren.

Dies änderte sich um die Jahrhundertwende in 32 Bit, aber die Echos leben weiter und sind tatsächlich subtiler, als es auf den ersten Blick erscheint. -1Umwandlung in eine vorzeichenlose 16-Bit-Ganzzahl, die der ( uid_tund gid_tan der Systemaufrufschnittstelle) zuvor war, ist natürlich 65535, wie Sie festgestellt haben. Das war also keine verwendbare UID oder GID.

Doch für die Vorteile der Programme, die die 16-Bit - API auf Kernel verwendet, die auf 32-Bit eingeschaltet hatten uid_tund gid_tdefiniert Linux einen „Überlauf UID“ und einen „Überlauf GID“. Dies war darauf zurückzuführen, dass an verschiedenen Stellen aufgrund des Castings zwischen 16-Bit und 32-Bit ziemlich unangenehme Interaktionen stattfanden. 16-Bit-Programme sahen UID 65536 als Superuser, wenn der Kernel dies nicht tat. Ältere Kernel sahen UID 131072 als Superuser, wenn der Anwendungscode dies nicht tat.

Die "Überlauf-UID" und "Überlauf-GID" bildeten im Wesentlichen alle 32-Bit-UIDs und GIDs ab, die größer als 65535 bis 65534 für 16-Bit-Code waren. Dies bedeutet, dass ein zweiter Wert, 0xFFFE, jetzt als echte UID oder GID-Wert unbrauchbar ist.

Natürlich ist auch die -1Umstellung auf den 32-Bit-UID- und GID-Typ unbrauchbar.

Systeme reservieren normalerweise den höchsten vorzeichenlosen Integer-Wert 0xffff (oder -1, wenn der Wert als vorzeichenbehaftete Ganzzahl interpretiert wird), um "ungültig" oder "nicht verwendet" anzuzeigen.
(0xffff ist natürlich 16-Bit. Einige Systeme verwenden 32-Bit-0xffffffff.)

Null kann dafür nicht verwendet werden, da es für die Root-Nutzung reserviert ist.
(Die Reservierung von 0 für root ist, wenn ich mich recht erinnere, eine POSIX-Konvention, die aus Gründen der Kompatibilität auch von fast jedem anderen Betriebssystem eingehalten wird.)