0 votos

Ocultación de carpetas por defecto a través de launchagent: no se aplica a los documentos

Es un poco extraño. Nuestra organización necesita permitir algún aspecto del acceso al almacenamiento local para acomodar el trabajo en archivos grandes sin escribir constantemente en las unidades de red. Trabajan en estos archivos y luego los copian en unidades montadas de AD. Quiero restringir los archivos locales en los que se puede escribir. Mi solución ha sido crear un launchagent que oculta todas las carpetas por defecto utilizando chflags hidden y schg en el primer inicio de sesión de un usuario. He utilizado un launchagent debido a la inminente amenaza de que se eliminen los hooks de inicio de sesión. El problema es que Documentos y Descargas nunca tienen aplicada la bandera hidden o immutable y no tengo ni idea de por qué. He añadido un retardo antes de que se ejecute el script, he añadido el script al archivo sudoers para que se pueda ejecutar como Root, he cambiado el código maté al finder y lo mantuve matado durante la duración del script, e incluso hice que el script sólo tratara de ocultar los documentos y nada funciona. Cualquier sugerencia se agradecería.

Para que sepas, he probado

find ~ -maxdepth 1 -mindepth 1 -type d -not -name '.*' -not -path "*/Library" -not -path "*/Desktop" -exec sudo chflags schg {} \; -exec sudo chflags hidden {} \;

sudo chflags hidden $HOME/Documents

sudo chflags hidden ~/Documents

sudo chflags -R hidden $HOME

edit: Olvidé mencionar que ejecutar manualmente el script con los mismos parámetros después de iniciar sesión funciona y oculta con éxito la carpeta Documentos y Descargas. Tiene que ser algo al iniciar la sesión.

0voto

Auspexis Puntos 16

Ok, lo he solucionado y explicaré la respuesta completamente si alguien tiene un problema similar.

Hay ciertas ocasiones en las que necesitarás ejecutar un start script/evento como sudo. Puede hacer esto usando LaunchDaemons que se ejecutan como sudo en el arranque del sistema y se ejecutan fuera de una sesión de usuario específica. Sin embargo, hay ocasiones en las que puede querer ejecutar algo como sudo en el contexto del usuario. Para resolver esto, inicialmente tenía un plist que llamaba a un ejecutable script con sudo como argumento, es decir sudo path/to/script/script.sh

El script fue añadido a visudo durante la postinstalación del agente, y tenía el siguiente aspecto %everyone ALL = (ALL) NOPASSWD: /Library/Scripts/script.sh . No lo hagas. Sólo entro en este detalle porque me parece la forma más lógica de hacerlo. Las listas actúan de forma extraña al analizar el parámetro sudo.

En su lugar, no te molestes en hacer ejecutable el script con chmod +x y deja sus permisos en 700 si es sensible. Añade un comando visudo con el parámetro bash/sh como %everyone ALL = (ALL) NOPASSWD: /bin/sh /Library/Scripts/script.sh .

A continuación, y lo más importante, crea un inicializador secundario script que llamará al principal script. Llama al script principal con sudo. Este script necesitará al menos 755 permisos. En el Plist, llame al inicializador script sin más parámetros que bash/sh.

En general, el proceso debería ser:

Postinstalación

echo '%everyone ALL = (ALL) NOPASSWD: /bin/sh /Library/Scripts/script.sh' | sudo EDITOR='tee -a' visudo

Plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.auspexis.myscript</string>
    <key>ProgramArguments</key>
    <array>
        <string>/bin/sh</string>
        <string>/Library/Scripts/init.sh</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
</dict>
</plist>

Inicializador script:

#!/bin/bash
sudo sh /Library/Scripts/script.sh 

Principal script:

Whatever you want

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