Forum Linux.général diverses questions : permissions, bash/exec, suid et sed

Posté par  .
Étiquettes : aucune
0
7
mar.
2008
permissions sur les dossiers:
est-ce que rw- et r-- sont equivalentes pour un dossier?
je pensais qu'avec un rw, je pourrais créer (ou renomer...) un fichier dans le dossier. ex :

$ ls -l
total 4
drw------- 2 erwan erwan 4096 2008-03-07 13:02 dossier
$ chmod u=rwx,go= dossier/
$ touch dossier/fichier
$ ls dossier/
fichier
$ chmod u=rw,go= dossier/
$ mv dossier/fichier dossier/fichier1
mv: accès de `dossier/fichier1': Permission non accordée


suid et script bash :
pourquoi un script bash (commençant par #!/bin/bash) et pour lequel le suid est placé est exécuté avec l'utilisateur qui lance le script et non pas par l'utilisateur propriétaire du fichier?


bash et exec :
d'après man bash :
exec [-cl] [-a name] [command [arguments]]
If command is specified, it replaces the shell. No new process
is created. The -c option causes command to be executed with
an empty environment.
Si l'option -c est utilisée, on lance command dans un environnement d'exécution vide.
Donc si je ne l'utilise l'option -c, toute variable déclarée et non exportée dans mon bash doit être accessible dans command?
par exemple :

monscript :
#!/bin/bash
echo \$VAR=$VAR



$ bash
$ VAR=toto
$ ./monscript
$VAR= #--> logique puisque je n'ai pas exporté ma variable VAR
$ exec ./monscript
$VAR= #--> le process monscript remplace le bash dans lequel il a été lancé. VAR a été déclarée dans ce bash.

Pourquoi n'a-t-il pas accès à la variable VAR? Pourquoi est-on obligé de l'exporter?


enfin,
question sed :

$ ls -ld /tmp/ | sed -n 's/\(^[a-z]*\)\(\)/\1 __/gp'

La regex définie un début ligne composé d'une succession (0 à n) de lettres minuscule que l'on inclu dans une sous-expression. Dans le remplacement, j'utilise \1 pour n'afficher que ce qui correspond à la première (et unique) sous-expression. Je le fait suivre de deux caractères __

$ ls -ld /tmp/ | sed -n 's/\(^[a-z]*\)\(\)/\1 __/gp'
drwxrwxrwt __ 7 root root 4096 2008-03-07 10:24 /tmp/

Je m'attendais à avoir ce résultat :
drwxrwxrwt __

Pourquoi sed m'affiche le reste? c'est-à-dire "7 root root 4096 2008-03-07 10:24 /tmp/"

La commande me permettant de le faire est (j'ajoute une sous-expression vide):

$ ls -ld /tmp/ | sed -n 's/\(^[a-z]*\)\(\)/\1 __/gp'
drwxrwxrwt __



Merci
  • # Quelques réponses :

    Posté par  . Évalué à 1.

    Pour le 1) c'est normal, parce que le bit x est à 0 sur le dossier, et comme tu n'as pas le droit d'exécution, tu n'as pas le droit d'entrer dans le dossier. D'ailleurs un ls dossier/ te l'aurais confirmé.
    Pour le suid, il est sans effet sur les scripts, parce que ça pose un problème de sécurité.
    Pour le problème des variables, il faudrait relire la page de manuel de bash, en particulier le chapitre sur la visibilité des variables.
    Enfin, pour la regexp, que veux-tu obtenir ?
    Si c'est la dernière ligne que tu cites, chez moi, elle ne donne pas ce que tu indiques sur ma machine.
    On peut s'en sortir avec awk ainsi :
    ls -ld /tmp/ | awk '{print $1 " __"}'
    Voilà, en espérant que ça t'aidera.
    • [^] # Re: Quelques réponses :

      Posté par  . Évalué à 3.

      Pour le suid, il est sans effet sur les scripts, parce que ça pose un problème de sécurité.

      C'est surtout parce que le programme qui est réellement exécuté à ce moment est l'interpréteur, qui lui va lire le script. C'est donc sur celui-ci qu'il faudrait poser les bits set[gu]id. Maintenant, execve est quand même une primitive du noyau (même si celles-ci passent désormais toutes par la glibc d'abord) et donc, la fonction pourrait être implémentée quand même, mais bon. Ce serait effectivement vachement limite ...

      On en parlait déjà ici :
      https://linuxfr.org/forums/10/23583.html
      • [^] # Re: Quelques réponses :

        Posté par  (site web personnel) . Évalué à 1.

        Attention, le comportement de setuid n'est pas le même sous tous les Unix.

        Un contournement est d'écrire un lanceur en C qui lui sera setuid.

        Bon de toute façon setuid c'est mal :)
  • # Bien lire les manpages

    Posté par  . Évalué à 3.

    $ exec ./monscript

    $VAR= #--> le process monscript remplace le bash dans lequel il a été lancé. VAR a été déclarée dans ce bash.


    Attention, grosse imprécision ! "exec" remplace le contenu d'un processus, donc l'image d'un programme exécutable en langage machine, par celle d'un autre.

    Ton shell n'a donc pas été remplacé par ton script mais par un autre shell, qui lui s'est initialisé comme il l'a voulu, et qui a interprété ton programme.

    Si tu veux demander à ton shell courant d'interpréter lui-même un script plutôt que d'ouvrir un sous-shell, par exemple pour relire ton .bashrc après modification, il faut "sourcer" ton script. Voir la commande source ou le point tout seul (synonymes).


    Pourquoi sed m'affiche le reste? c'est-à-dire "7 root root 4096 2008-03-07 10:24 /tmp/"

    Parce que tu as collé ton marqueur de début de ligne "^" à l'intérieur de l'expression régulière elle-même. Fous-le au tout début de ton motif, avant le \( et ça devrais marcher beaucoup mieux.
  • # sed

    Posté par  . Évalué à 2.

    Pourquoi sed m'affiche le reste?

    parce que sed applique le remplacement sur le motif de recherche. Il se trouve que ton motif s'applique à une partie de la ligne, pas à toute la ligne. Sed effectue donc le remplacement sur ce bout de ligne, et laisse la fin de ligne inchangée.

    Tu peux t'en sortir en rajoutant un .* à la fin de ton motif de recherche comme ça :
    ls -ld /tmp/ | sed -n 's/\(^[a-z]*\)\(\).*/\1 __/gp'
    • [^] # Re: sed, ou stat

      Posté par  (site web personnel) . Évalué à 2.

      Pour extraire les permissions de /tmp/, ça va, mais pour un répertoire quelconque,

      ls -ld /usr/ | sed -n -e 's/^\([a-z-]*\).*/\1/p'

      serait mieux -- l'option g est inutile, il ne peut y avoir plusieurs remplacements avec l'ancre ^.

      Une solution plus simple est

      stat -c'%A' /tmp/

      (man stat pour les formats disponibles).
  • # environnement

    Posté par  . Évalué à 1.

    Si on fait

    TOTO=paf
    exec machin

    dans un shell, c'est un peu comme avoir un programme en C qui fait

    int toto=5;

    exec(truc);

    Dans le programme truc, même s'il y a une variable de nom toto, elle ne vaudra pas 5 au lancement du programme. Pareil en bash.
    • [^] # Re: environnement

      Posté par  . Évalué à 2.

      ben si, mais pour les variables d'environnement uniquement,
      % export TOTO=paf
      % exec sh -c 'echo $TOTO; sleep 1'
      TOTO
      • [^] # Re: environnement

        Posté par  . Évalué à 2.

        merde boulet, ça affiche "paf" et pas "TOTO" évidemment :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.