3 votos

¿El bit pegajoso en /tmp no hace lo que se supone que debe hacer?

Con frecuencia ejecuto un script que crea tres archivos en /tmp y luego los mueve al directorio de destino. Me desconcertaron los mensajes de error:

mv: ./20170608-l.gpx: set owner/group (was: 503/0): Operation not permitted
mv: ./20170608-u.gpx: set owner/group (was: 503/0): Operation not permitted
mv: ./20170608.csv: set owner/group (was: 503/0): Operation not permitted

El script no utiliza sudo, por lo que la rueda de grupo (cero) parecía extraña. Comprobando /tmp (/private/tmp) muestra que el sticky bit está en él. Pero forzar que el grupo sea wheel (que espero que ocurra) no es lo que Wikipedia (citando una página man de Leopard) dice que hará. E impedirme cambiar el grupo en la copia tampoco. La copia termina con el mismo propietario -yo- y mi grupo -personal- así que en realidad hizo lo que decía que no estaba permitido.

Puedo ver un razonamiento para lo que dice la página de manual, pero ¿por qué el mensaje de error dice que algo diferente no estaba permitido cuando en realidad hizo exactamente eso? ¿Y por qué se crean archivos en /tmp con la rueda de grupo cuando no es para eso para lo que sirve el sticky bit?

/tmp es Root/wheel como se esperaba,

WGroleau@MBP ~ % ls -latde@ /private/tmp
drwxrwxrwt  7 root  wheel  224 Dec 21 09:58 /private/tmp

pero el documento mencionado dice que el sticky bit impide que lo borre otra persona que no sea el propietario. Como yo era el propietario, eso no importa. Pero no dice lo que yo pensamiento lo que significaba, que era anular el grupo del creador. Sin embargo, esto último es lo que ocurrió. Y entonces el mensaje de error afirma falsamente que no fue capaz de cambiar el grupo al mío. No estoy seguro de si es necesario cambiar el grupo cuando el destino no tiene un sticky bit:

WGroleau@MBP ~ % ls -late@d /Volumes/Sidecar/Sort_By_Date/2017/06/08
drwxrwxr-x  16 WGroleau  staff  512 Dec 20 23:35 /Volumes/Sidecar/Sort_By_Date/2017/06/08

4voto

El código fuente de mv está disponible en Github La parte relativa al error se encuentra en la línea 448.

oldmode = sbp->st_mode & ALLPERMS;
if (fchown(to_fd, sbp->st_uid, sbp->st_gid)) {
    warn("%s: set owner/group (was: %lu/%lu)", to, (u_long)sbp->st_uid, (u_long)sbp->st_gid);
    if (oldmode & (S_ISUID | S_ISGID)) {
        warnx("%s: owner/group changed; clearing suid/sgid (mode was 0%03o)", to, oldmode);
        sbp->st_mode &= ~(S_ISUID | S_ISGID);
    }
}

Lo que realmente ocurre mv es la siguiente:

  • Como se trata de un archivo normal que se mueve a otro sistema de archivos, el comando no puede utilizar el estándar rename() pero utiliza una función interna para crear un nuevo archivo en el sistema de archivos de destino, copiar el contenido y, a continuación, eliminar el archivo de origen.
  • Inicialmente, el archivo de destino se crea con el grupo por defecto del usuario (normalmente staff )
  • Una vez realizada la copia, el comando intenta aplicar el propietario y el grupo del archivo de origen al archivo de destino recién creado (el comando fchown() en la segunda línea del fragmento de código anterior
  • Archivos en /tmp pertenecer a un grupo wheel pero los usuarios normales no forman parte de ese grupo, así que fchown() falla, dando lugar al mensaje de advertencia.

Esto también significa que sudo mv /tmp/foo /Volumes/External/ tendrá éxito sin previo aviso:

$ touch /tmp/foo
$ mv /tmp/foo /Volumes/EXT
mv: /Volumes/EXT/foo: set owner/group (was: 502/0): Operation not permitted
$ touch /tmp/foo
$ sudo mv /tmp/foo /Volumes/EXT
$

3voto

Jose Chavez Puntos 645

Su pregunta proviene de un malentendido de por qué los archivos tienen wheel como grupo - ya que simplemente no tiene nada que ver con la parte pegajosa.

La parte adhesiva funciona según lo previsto y hace lo que siempre ha hecho. No hay ningún tratamiento especial para el /tmp carpeta en ese sentido.

En general, un usuario que tiene permisos de escritura y ejecución para un directorio puede renombrar y eliminar archivos de ese directorio. Como se ve en su pasta, todos los demás tienen permisos de escritura y ejecución en el directorio /tmp directorio. Esto crea el problema de que cualquier usuario puede borrar los archivos temporales de otros usuarios. Esto no es deseable.

El sticky bit resuelve esto declarando al sistema que no quieres la semántica habitual de los permisos de directorio. En su lugar, sólo el propietario del archivo, el propietario de la /tmp o el directorio root el usuario puede renombrar y borrar archivos en /tmp .

Así que esa era la parte pegajosa - nada en esa explicación decía nada sobre el grupo wheel .

Esto proviene de un hecho básico sobre los permisos del sistema de archivos en sistemas tipo Unix, como por ejemplo MacOS. Así, cuando se crea un fichero en estos sistemas, el grupo del nuevo fichero es por defecto el grupo de la carpeta en la que se crea el fichero. Como el /tmp tiene el grupo wheel los nuevos archivos creados en el /tmp tendrá por defecto el grupo wheel .

Cuando más tarde intente mover archivos desde /tmp a otros sistemas de archivos, el mv intentará que el archivo de destino tenga el mismo propietario y grupo que el archivo original. Esto falla porque no se puede establecer el grupo del nuevo archivo a wheel - en su lugar, el archivo acaba teniendo el grupo por defecto, es decir, el grupo de la carpeta donde se crea el archivo.

AppleAyuda.com

AppleAyuda es una comunidad de usuarios de los productos de Apple en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X