[script setuid] ne fonctionne pas

Bonjour,

J'ai fait le petit script ci dessous :

Code:

---

1 2	#!/bin/bash tail -n5 /var/log/messages

---

J'ai fait un chown root:root sur ce script.
Puis un chmod 4777.

Je me log en utilisateur standard et lance ce script.
Et là j'obtiens un superbe

Citation:

---

tail: Ne peut ouvrir `/var/log/messages' en lecture: Permission non accordée

---

Voici ce que donne un ls -alh mon_tail

Code:

---

-rwsrwxrwx 1 root root 39 févr. 23 23:42 /home/winnt/scripts/mon_tail

---

Je ne vois pas pourquoi ca ne passe pas.
Quelqu'un a une idée ?

setuid ne fonctionne pas sur les scripts.

Et *****

A tout hasard aurais tu une idée lumineuse pour avoir un tail en tant qu'utilisateur non privilégié (et sans sudo hein ;)) .

Salut,

Citation:

---

Envoyé par Winnt

Et *****

A tout hasard aurais tu une idée lumineuse pour avoir un tail en tant qu'utilisateur non privilégié (et sans sudo hein ;)) .

---

J'imagine que tu ne peux / veux pas mettre ton utilisateur dans un groupe autorise a lire le fichier que tu souhaites?

A ta place je ferais une copie setuid de tail lui-meme avec un chemin "securise", par exemple un sous-repertoire de $HOME avec permission 700. Il suffit ensuite d'adapter ton script avec le chemin absolu vers "mon-tail"

Je crains que cela ne suffise pas. :(
C'est le fichier /var/log/messages qui n'est accessible qu'à root et aux membres du groupe adm, pas la commande tail; celui qui lance le script ou qui exécute la commande n'est toujours qu'un utilisateur...
?

Mais si tail est un executable setuid appartenant a root n'importe quel utilisateur le lancant aura le droit de lire les fichiers de root. C'est aussi pourquoi je conseille de faire ca sur une copie dans un repertoire "prive" (ce serait dommage d'autoriser tous les utilisateurs a lire /etc/passwd par exemple).

À mon avis, le mieux est de créer un groupe spécial, genre msgro (messages read-only) et d'ajouter dans ce groupe la liste des users autorisés. Il faut alors changer le groupe du fichier (chgrp msgro /var/log/messages) puis changer ses droits (chmod g+r /var/log/messages).

Edit: le fichier /etc/passwd est lisible par tout le monde. C'est le fichier /etc/shadow qui ne l'est pas (lisible par personne sur Fedora 12).

Salut,

La création d'un groupe spécifique pourrait être une idée.
Mais il n'y a pas un risque lors de la rotation des logs ?
Le fichier en cours étant archiver un nouveau est créer. Et à priori (j'ai pas tester) avec root:root non ?

Citation:

---

Envoyé par tonton fred

J'imagine que tu ne peux / veux pas mettre ton utilisateur dans un groupe autorise a lire le fichier que tu souhaites?

---

Je pourrais le faire c'est ma machine perso. Mais ca me chagrine à tort ou à raison :D

Tu as parfaitement raison: si logrotate supprime le fichier, il sera recréé avec les droits par défaut: root:root.

Pas de solution évidente, ni du côté des liens (symboliques ou durs), ni du côté du sticky-bit groupe du répertoire /var/log. Je sèche...

man logrotate:

Citation:

---

Here is more information on the directives which may be included in a logrotate configuration file:
<...>
create mode owner group
Immediately after rotation (before the postrotate script is run) the log file is created (with the same name as the log file just rotated). mode specifies the mode for the log file in octal (the same as chmod(2)), owner specifies the user name who will own the log file, and group specifies the group the log file will belong to. Any of the log file attributes may be omitted, in which case those attributes for the new file will use the same values as the original log file for the omitted attributes. This option can be disabled using the nocreate option.

---

Donc aucun probleme a ce niveau la (logrotate est la pour faciliter la vie ;) )

winnt, quelles sont exactement tes contraintes? Plusieurs possibilite ont ete deja abordee mais ce n'est toujours pas clair pour moi ce que tu cherches:
-creer une "commande" (au sens large) pour qu'un utilisateur non privilegie puisse lire tes logs
- donner plus de droits a ton utilisateur
- modifier les droits des logs

Salut,

Je suis en train de me mettre en place un monitoring de base pour mon pc principal sous gentoo (pas la peine de me parler de zabix ou nagios).
Et il m'intéresse d'avoir quelques lignes de certains fichiers de log (logs d'emerge, messages,...) histoire de toujours avoir un oeil dessus au cas ou... (et un peu pour le fun aussi ;)).
Toutefois, je n'ai pas envie de prendre de gros risques au niveau de la sécurité de mon PC.
J'avais donc pensé au SETUID sur un script mais effectivement après réflexion c'est un trou de sécurité. Raison sans doute pour laquelle les script ne peuvent l'utiliser.

Et donc si je comprends bien l'extrait du man posté par tonton fred l'uid et gid du fichier de log sont conservés lors de la rotation.

En ce cas la création d'un groupe spécifiquement dédié à la lecture des logs comme suggéré par jmelyn pourrais en effet être la solution.
Un groupe lis_log avec exclusivement des droits de lecture pourrait peut être fonctionner (chmod 640 je pense). Mais il me va tout de même falloir faire des tests afin de m'en assurer (le comportement de chaque programme générant des logs est-il identique ? A voir).

D'expérience, je dirais qu'un user standard devrait rester standard, sans droit spécial sur certains fichiers ou répertoires système. Tu nous exposes un cas particulier mais il peut en exister plein d'autres si l'on veut. Dans ce cas, lors d'une réinstallation, c'est galère de retrouver toutes les combines pour obtenir le même fonctionnement que précédemment.

Ce que je fais pour moi est de pouvoir passer root très facilement (et sur n'importe quelle machine): J'ai créé un groupe spécial restreint d'administrateurs, et j'ai modifié la configuration de la commande sudo. Ainsi je passe root en tapant simplement sudo -i, sans même taper de mot de passe. À moi de ne pas laisser une session ouverte sans surveillance. Cela fait donc deux fichiers à modifier pour toutes les manips d'admin.

Si ça peut t'aider...

Salut,

Donc ce serait un truc dans ce gout là à mettre en place avec sudo :

Code:

---

1 2 3

Cmnd_Alias TAIL= /bin/tail (chemin à vérifier) toto ALL= NOPASSWD: TAIL

---

et dans mon code

Code:

---

sudo -i tail -n5 /var/log/messages

---

Dans ce cas effectivement cela permet de grandement limiter les risques.

Citation:

---

Envoyé par jmelyn

D'expérience, je dirais qu'un user standard devrait rester standard, sans droit spécial sur certains fichiers ou répertoires système

---

C'est aussi pour cela que j'ai poster ici et pris le temps de lire vos réponses.

C'est à peu près ça, en version courte puisque tu ne définis pas de groupe mais juste la liste des utilisateurs. Ça me semble un peu contraignant de définir la liste des commandes admin possibles parce qu'il risquera d'un manquer. L'argument ALL du fichier sudoers veut dire "sur toutes les machines existantes". Si tu n'en as qu'une seule, pas de problème. Sinon à réfléchir suivant l'organisation que tu veux avoir.

L'option -i (interactive login) de sudo est assez récente et permet de changer d'utilisateur, comme su -, pas pour juste lancer une commande. La commande est donc: sudo tail -5 /var/log/messages.

Salut,

Citation:

---

Envoyé par jmelyn

C'est à peu près ça, en version courte puisque tu ne définis pas de groupe mais juste la liste des utilisateurs. Ça me semble un peu contraignant de définir la liste des commandes admin possibles parce qu'il risquera d'un manquer.

---

C'est en effet une possibilité. Mais d'un autre coté je regarde cela pour un petit monitoring perso avec conky sans forcément avoir les besoins ni les contraintes d'un "administrateur".
Par exemple voir que l'emerge de la mort que j'ai lancé en est au 5/179 paquets de compiler. Voilà un peu ce que je recherche.

En tout les cas merci à tous de vos contributions. J'ai encore eu le plaisir d'en apprendre plus sur linux avec vos constructives interventions.