☰

Von NFS gebootet. Linux hat keine Berechtigung für den Befehl „su“

tag-icon • tag-icon linux permissions boot su u-boot
Von NFS gebootet. Linux hat keine Berechtigung für den Befehl „su“

Ich habe Linux mit einem Android-System gebootet NFS. Und jetzt muss ich den Befehl als Superuser ausführen minicom. Aber das System erlaubt mir nicht, in den Superuser-Modus zu wechseln. Jedes Mal, wenn ich Folgendes eingebe:

shell@blaze_tablet:/ $ su

Ich verstehe:

su: permission denied

Ich habe einen Parameter bootargsin u-boot hinzugefügt, androidboot.selinux=disabledvon dem ich dachte, er würde helfen. Aber das tut er nicht. Kann das Problem an der Berechtigung für einige Dateien liegen NFS? Oder habe ich einen Parameter übersehen bootargs?

Aktualisieren

Der Inhalt meiner /etc/exportsDatei

# /etc/exports: the access control list for filesystems which may be exported
#       to NFS clients.  See exports(5).
#
# Example for NFSv2 and NFSv3:
# /srv/homes       hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check)
#
# Example for NFSv4:
# /srv/nfs4        gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check)
# /srv/nfs4/homes  gss/krb5i(rw,sync,no_subtree_check)
/export/rfs    *(rw,nohide,insecure,no_subtree_check,async,no_root_squash)

Antwort1

Sie schrieben:

Ergebnis der Ausführung vonls -l $(type -p su)

-rwxr-xr-x root root 157400 2016-04-21 19:11 su

Da liegt Ihr Problem. suEs fehlt das Setuid-Root-Bit. Die Berechtigungen sollten so aussehen:

-rwsr-xr-x 1 root root 40040 Nov 12  2015 /bin/su

Für diese Situation gibt es drei Möglichkeiten.

  1. Die suausführbare Datei auf dem Server ist nicht setuid (überprüfen Sie dies ls -l $(type -p su)auf dem Server).
  2. nosuidDer NFS-Mount auf dem Client enthält das Setuid-Bit nicht oder schließt es explizit aus. Stellen Sie sicher, dass Ihr Befehl es nicht enthält mount, und fügen Sie es im Zweifelsfall suidals explizite Option hinzu.
  3. Die Android-Sicherheit ist völlig anders implementiert als die Unix/Linux-Sicherheit. Wenn das der Fall ist, kann ich Ihnen nicht weiterhelfen

Antwort2

Dies passiert normalerweise, wenn die NFS-Freigabe nicht ordnungsgemäß exportiert wird.

Standardmäßig rootist der Benutzer zugeordnet nobody. Das bedeutet, dass Sie beim Ausführen su(was ein Suid-Root ist) versuchen, als Benutzer auf Dateien auf dem NFS-Server zuzugreifen nobody... und dies lässt Sie nicht lesen /etc/shadowund ähnliches.

no_root_squashSie haben nicht gesagt, welcher Ihr NFS-Server ist, aber wenn es der normale Linux-Server ist, müssen Sie ihn zum Export hinzufügen .

z.B

/directory client(rw,no_root_squash,async,insecure)

rootJetzt greift der Benutzer auf die Dateien zu, als ob es sich um die UID 0 handeln würde, und kann so die geschützten Dateien lesen.

verwandte Informationen