¿Encontrar archivos que un usuario no puede leer?

Quiero encontrar archivos que un usuario en particular no podrá leer.

Suponga que el nombre de usuario es "usuario123" y están en un grupo llamado "usuario123". Quiero encontrar archivos que, si son propiedad del usuario 123, tengan activado u+r; en su defecto, si el archivo es del grupo user123, debería tener g+r activado; en su defecto puede tener o+r encendido.

Dado que GNU find tiene "-legible", podría hacer esto:

sudo -u user123 find /start ! -readable -ls

Sin embargo, el proceso debe ejecutarlo un usuario que no tenga acceso a Sudo. Por lo tanto, probé esto:(no marca o+r pero eso no es importante en este momento)

find /start ( -user user123 ! -perm -u=r  ) -o ( -group user123 ! -perm -g=r  ) -ls

pero enumera este archivo:

272118    4 -rw-------   1 user123   user123       3243 Jul  3 19:50 /start/blah/blah/file.txt

Este archivo es el único archivo bajo /start que es propiedad de user123 con g=r apagado. Es como si find estuviera interpretando el -u=r como -g=r .

Decidí intentar invertir la lógica y en su lugar probar not ( truth ) en cambio:

find /etc/puppet ! ( ( -user puppet -perm -u=r  ) -o ( -group puppet -perm -g=r ) -o ( -perm -o=r ) )  -ls

¡Eso funciona!

¿Por qué el find original ¿fallar? ¿Es un error en find? (poco probable) o la lógica es incorrecta?

Actualización: Tenía la lógica equivocada. Como se indica a continuación, desde
! ( A || B || C ) ==( !A &&!B &&!C )
estas son las dos sentencias equivalentes:

find /start ! ( ( -user user123 -perm -u=r ) -o ( -group user123 -perm -g=r ) -o ( ! ( -user user123 -o -group user123 ) -perm -o=r ) ) -ls
find /start ! ( -user user123 -perm -u=r ) ! ( -group user123 -perm -g=r ) ! ( ! ( -user user123 -o -group user123 ) -perm -o=r ) -ls

Mi objetivo era no tener que probar el usuario/grupo dos veces. Lo que realmente necesito es una estructura if-then-else más complicada, que probablemente solo sería posible si hubiera un operador -xor. Podría construir un xor a partir de y/o/no, pero sería más complejo que las dos soluciones anteriores.

Respuesta aceptada:

La lógica está mal. Estás pensando que este archivo no debería haber estado en la lista porque es propiedad de user123 y tiene la r del usuario conjunto de bits. Sin embargo, aparece porque coincide con el segundo criterio (pertenece al grupo user123 y tiene la r del grupo poco desactivado).

Su segunda versión funciona debido a una de las leyes de Morgan:negar el OR lógico de un grupo de declaraciones es lógicamente equivalente a hacer AND en la negación de las declaraciones individuales. En otras palabras:

 ! ( A || B || C ) == ( !A && !B && !C )

Así que el trabajo find está buscando un archivo que

• No es (propiedad del usuario user123 y legible por dicho usuario) Y
• No es (propiedad del grupo user123 y legible por dicho grupo) Y
• No es legible para todo el mundo.

Relacionado:Linux:dado un hash de confirmación de git, ¿cómo averiguar qué versión del kernel lo contiene?

mientras que el primero find está buscando un archivo que

• Es propiedad del usuario user123 y no legible por dicho usuario O
• Es propiedad del grupo user123 y no legible por dicho grupo O (si lo ha completado)
• No es legible para todo el mundo

Por lo tanto, un archivo que coincida con CUALQUIERA de los 3 criterios anteriores (y no necesariamente todos) aparecerá en la lista como ha visto.

Editar

Por cierto (después de ver tu perfil), soy un gran admirador de tu libro de O'Reilly 🙂