Si desea implementar su chgrp -R nobody /whatever mientras conserva el bit setuid, puede usar estos dos find comandos
find /whatever ! -type l -perm -04000 -exec chgrp nobody {} + \
-exec chmod u+s {} +
find /whatever ! -type l ! -perm -04000 -exec chgrp nobody {} +
El find ... -perm 04000 La opción recoge archivos con el conjunto de bits setuid. El primer comando luego aplica el chgrp y luego un chmod para restablecer el bit setuid que se ha eliminado. El segundo aplica chgrp a todos los archivos que no tienen un bit setuid.
En cualquier caso, no quieres llamar a chgrp o chmod en los enlaces simbólicos, ya que eso afectaría a sus objetivos, de ahí el ! -type l .
Borrado de bits SUID y SGID en chgrp (o chown ) es perfectamente razonable. Es una medida de seguridad para prevenir problemas de seguridad. Para SGID (en ejecutables, supongo) significa ejecutar este programa con el grupo efectivo del propietario del grupo .
Si cambia el propietario del grupo, en términos de seguridad y control de acceso, esto es algo completamente diferente, es decir, en lugar de ejecutarse con el grupo efectivo uvw el programa ahora se ejecuta con el grupo efectivo xyz .
Por lo tanto, debe restaurar el bit SUID o SGID explícitamente en el cambio de propiedad.
Anexo:sobre la afirmación de que chgrp (o chown) solo debe borrar SGID (o SUID, respectivamente)
Por chown ing o chgrp Al pedirle que cambie la configuración de seguridad de un ejecutable, esta es una razón suficiente para borrar cualquier atributo de elevación de privilegios. El poder de Unix proviene de la simplicidad conceptual, y la seguridad de Unix ya es bastante complicada. Con este fin, eliminar SUID y SGID en cualquier cambio de propiedad es simplemente una red de seguridad; después de todo, en la historia de Unix/Linux hubo bastantes vulnerabilidades debido a configuraciones erróneas de SUID o SGID.
Así que no hay una razón más profunda por la que Unix se comporte de esta manera, es solo una decisión de diseño conservador.
La limpieza del setuid , setgid bit (al menos en Linux) en no directorios lo realiza el kernel en el chown() llamada al sistema realizada por chgrp , no por chgrp sí mismo. Entonces, la única forma es restaurarlo después.
También borra las capacidades de seguridad.
Entonces, en GNU Linux:
chown_preserve_sec() (
newowner=${1?}; shift
for file do
perms=$(stat -Lc %a -- "$file") || continue
cap=$(getfattr -m '^security\.capability$' --dump -- "$file") || continue
chown -- "$newowner" "$file" || continue
[ -z "$cap" ] || printf '%s\n' "$cap" | setfattr --restore=-
chmod -- "$perms" "$file"
done
)
Y ejecuta (como root ):
chown_preseve_sec :newgroup file1 file2...
para cambiar el grupo al intentar conservar los permisos.
De forma recursiva, podrías hacer:
# save permissions (and ACLs). Remove the "# owner" and "# group" lines
# to prevent them being restored!
perms=$(getfacl -RPn . | grep -vE '^# (owner|group): ')
# save capabilities
cap=$(getfattr -Rhm '^security\.capability$' --dump .)
chgrp -RP nobody .
# restore permissions, ACLs and capabilities
printf '%s\n' "$perms" | setfacl --restore=-
[ -z "$cap" ] || printf '%s\n' "$cap" | setfattr -h --restore=-
(todo eso suponiendo que nada interfiera con los archivos al mismo tiempo).