☰

Arrancado desde NFS Linux no tiene permiso para el comando su

tag-icon • tag-icon linux permissions boot su u-boot
Arrancado desde NFS Linux no tiene permiso para el comando su

Arranqué Linux desde NFSel sistema Android. Y ahora tengo que ejecutar el comando como superuso en minicom. Pero el sistema no me permite cambiar al modo de superusuario. Cada vez que escribo:

shell@blaze_tablet:/ $ su

Veo:

su: permission denied

Hay un parámetro que bootargsagregué en u-boot androidboot.selinux=disabledque pensé que sería útil. Pero no es así. ¿Puede haber un problema con el permiso para algunos archivos NFS? ¿O me perdí algún parámetro bootargs?

Actualizar

El contenido de mi /etc/exportsarchivo.

# /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)

Respuesta1

Tu escribiste:

resultado de la ejecución dels -l $(type -p su)

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

Ahí está tu problema. sufalta el bit raíz setuid. Los permisos deberían verse así:

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

Hay tres posibilidades para esta situación.

  1. El suejecutable en el servidor no es setuid (consulte con ls -l $(type -p su)el servidor)
  2. El montaje NFS en el cliente no incluye (o excluye explícitamente) el bit setuid. Asegúrese de no tenerlo nosuidbajo su mountcontrol y, en caso de duda, agréguelo suidcomo una opción explícita
  3. La seguridad de Android se implementa de manera completamente diferente a la seguridad de Unix/Linux. Si este es el caso no puedo ayudarte más

Respuesta2

Normalmente, esto sucede si el recurso compartido NFS no se exporta correctamente.

De forma predeterminada, el rootusuario está asignado a nobody. Esto significa que cuando intentes ejecutar su(que es suid root), intentarás acceder a los archivos en el servidor NFS como usuario nobody... y esto no te permitirá leer /etc/shadowni similares.

No dijiste cuál es tu servidor NFS, pero si es el normal de Linux, entonces debes agregarlo no_root_squasha la exportación.

p.ej

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

Ahora el rootusuario accederá a los archivos como si fuera uid 0 y así podrá leer los archivos protegidos.

información relacionada