>L'étoile dans la deuxieme colonne signale juste que les shadows password
>sont utilisés et il faut vérifier dans /etc/shadow.
Desole ce n'est pas une etoile c'est un x que je voulais dire :(
> Je viens de faire l'essai mais j'etais deja convaincu, cela ne fonctionne pas.
>
> simple test :
> lancé sous le compte root
> su nobody -c "/bin/ls /tmp > /tmp/ttt"
> devrait te donner un fichier /tmp/ttt ou il a le resultat de la commande ls
> et bien, rien n'est crée car l'entrée nobody dans /etc/passwd est :
>
> nobody:x:508:100:User Nobody:/tmp:/bin/true
>
Ah! moi je n'ai pas ca comme entree (mais celle que tu donne en dessous)
Mea Culpa: le parametre -c de su permet de passer la commande a certains shell
(par defaut /bin/sh) qui l'interprete puis sort au lieu de proposer un
prompt...
Dans ton cas tu execute /bin/true (qui lance un shell d'ailleurs!!) au lieu de
/bin/sh.
> par contre un
> su eldin -c "/bin/ls /tmp > /tmp/ttt" fonctionne trés bien !
>
> cela fonctionne si l'entrée est :
> nobody:x:508:100:User Nobody:/tmp:
> mais la, c'est dangereux car nobody a le shell par défaut donc /bin/sh !!
> Et il donc possible de se connecter sur ce compte via telnet ou ftp,
> en aillant le mot de passe bien sur !
Mais y'a pas de mot de passe (le x dit qu'il ne faut pas se loguer sous le nom
de cet utilisateur => par de telnet ni de ftp). Il est donc *obligatoire* de
passer par root pour executer qq chose en nobody. La protection est donc
reporte sur la facilite de se connecter en root (qui est assez bien faite par
pam d'ailleurs).
>
> Ce que je cherche, c'est faire excécuter une commande shell à un utilisateur
> n'aillant pas de shell, c'est à dire /bin/true ou /bin/false défini comme
> shell par défaut.
En fait, tu n'est pas oblige de lancer un shell a la connection, c'est
seulement nous pauvres humains avons besoin d'un shell pour nous servir de
notre belle machine, mais rien n'interdit de donner une autre commande dans
/etc/passwd (/bin/true par exemple). Tu peux donc d'efinir un utilisateur
ayant un tache specialisee et donner un executable ou une commande traitant
cette tache dans /etc/passwd. L'inconvenient est qu'il faut un utilisateur par
commande...
Hope this Helps
Stephane.
