Ich verwende ein Chromebook und möchte über die Shell im Android-Container navigieren. Der Container ist unter dem Pfad gemountet /run/containers/android_XXXXX. Beim Versuch, cdin das Verzeichnis zu wechseln, wird mir angezeigt, dass Permission Denied. Ich habe versucht, den Befehl als auszuführen sudo, aber aus irgendeinem Grund ist der Befehl nicht mehr zugänglich. Ich habe es im Verzeichnis cdausgeführt , aber ohne Erfolg.chmod u+x
Welche Schritte kann ich von hier aus unternehmen?
Ich habe statdas Verzeichnis ausgeführt, das Folgendes zurückgibt:
File: ‘android_XXXXXX/’
Size: 80 Blocks: 0 IO Block: 4096 directory
Device: fh/15d Inode: 59640 Links: 3
Access: (0700/drwx------) Uid: (655360/ UNKNOWN) Gid: (655360/ UNKNOWN)
Context: u:object_r:tmpfs:s0
Access: 2016-10-31 04:04:52.680000040 +0000
Modify: 2016-10-31 04:04:52.200000040 +0000
Change: 2016-10-31 04:44:54.990001186 +0000
Birth: -
Antwort1
Das Verzeichnis ist drwx------so, dass nur jemand mit der UID 655350(die nicht in der Kennwortdatei aufgeführt ist) es lesen oder betreten kann.
sudo cdDass der Befehl nicht gefunden werden kann cd, ist zu erwarten, da er in die Shell integriert ist. Wenn er nicht integriert wäre, würde er nicht funktionieren. Angenommen, Ihre aktuelle Shell hat die Prozess-ID 54000 und Sie haben den Befehl /bin/cd ausgeführt. Es könnte sich um die PID 54309 handeln. Er würde das Verzeichnis für Prozess 54309 ändern und dann beenden. Prozess 54000 wäre noch immer in seinem ursprünglichen Verzeichnis.
chmod u+xändert user (owner)die Berechtigung.
Was Sie wollen, istsudo chmod go+rx /run/containers/android_XXXXX
Antwort2
Zusätzlich zur Überprüfung der Berechtigungen, wie von @icarus erwähnt, müssen Sie auch Ihre ACLs (Access Control Lists) überprüfen, um getfaclsicherzustellen, dass es keine Regeln gibt, die die grundlegenden Dateizugriffsrechte außer Kraft setzen.
HINWEIS: Wenn getfacldies auf Ihrem System nicht vorhanden ist, liegt das wahrscheinlich nicht daran.
Beispiel-ACL, das sollte kein Problem sein.
$ getfacl test/
# file: test/
# owner: root
# group: root
user::rwx
group::r-x
other::r-x
Dies zeigt an, dass außer den standardmäßigen POSIX-Zugriffsregeln keine zusätzlichen ACL-Regeln angewendet werden. Sie können sehen, dass es ls -aldhinsichtlich der Berechtigungen mit der Ausgabe von übereinstimmt. (Das -dArgument to lsweist an, Ihnen das Verzeichnis selbst anzuzeigen, nicht dessen Inhalt.)
$ ls -ald test/
drwxr-xr-x 2 root root 4096 May 8 19:11 test/
Beispiel einer ACL, die Probleme verursachen könnte.
$ getfacl test/
# file: test/
# owner: root
# group: root
user::rwx
user:mc:r--
group::r-x
mask::r-x
other::r-x
$ ls -ald test/
drwxr-xr-x+ 2 root root 4096 May 8 19:11 test/
In diesem Fall würde man beim Betrachten der Ausgabe von ls -aldnicht denken, dass es ein Problem geben würde. Da jedoch ACL-Regeln über POSIX-Regeln gelten, mckönnte der Benutzer aufgrund fehlender Ausführungsberechtigungen nicht in das Verzeichnis wechseln, obwohl die anderen Berechtigungssätze ihm ansonsten den Zugriff erlauben würden mc.
Zu beachten ist jedoch, dass die Eigentümerberechtigungen Vorrang vor allen anderen ACL-Regeln zu haben scheinen und ich glaube, dasselbe gilt für die Gruppeneigentümerberechtigungen.
Weitere Informationen zu ACLs finden Sie im Arch Wiki.https://wiki.archlinux.org/title/Access_Control_Listswenn Sie daran interessiert sind, mehr über sie zu erfahren.
Verständlicherweise möchten Sie nicht immer prüfen, getfaclob das Ihr Problem ist, oder Sie vergessen es vielleicht. Glücklicherweise ls -alteilt Ihnen mit mit, wenn zusätzliche ACL-Regeln angewendet werden. Wenn Sie sich die Ausgabe von ansehen ls -al, können Sie +am Ende der Liste der Berechtigungsbits ein sehen, wenn ACL-Regeln angewendet werden, und andernfalls wird es nicht angezeigt (zumindest scheint das bei meinen kurzen Tests der Fall zu sein).
TLDR: Wenn Sie +in der Berechtigungsliste von ein sehen ls -al, überprüfen Sie die Zugriffskontrollliste ( getfacl).