Changer date/heure utilisateur non-root

Version imprimable

27/10/2014, 10h30
nesswaw

Changer date/heure utilisateur non-root

Bonjour,

Est-il possible de donner des droits d'accès à un user non root afin de changer la date/heure grâce à la commande date ?

Je dois faire une tâche cron qui:

- Arrête un service
- Change la date
- Change l'heure
- Démarre le service

Le problème est que pour arrêter/démarrer le service c'est un script custom spécifiquement fait pour cet user non root, pas possible de le lancer en root.

Ou alors dans mon cron, si je lance depuis root, je peux exécuter une commande avec un autre user?

Merci d'avance
27/10/2014, 10h46
N_BaH

Bonjour,

Citation:

Envoyé par nesswaw

Est-il possible de donner des droits d'accès à un user non root afin de changer la date/heure grâce à la commande date ?

autant que je ~~sache~~ puisse le dire, non.

Citation:

Ou alors dans mon cron, si je lance depuis root, je peux exécuter une commande avec un autre user?

oui, avec su.
27/10/2014, 12h01
jlliagre

Citation:

Envoyé par nesswaw

Est-il possible de donner des droits d'accès à un user non root afin de changer la date/heure grâce à la commande date ?

C'est en général possible mais pas recommandé du tout pour des raisons de fiabilité et de sécurité (copie du binaire date dans un répertoire protégé accessible uniquement par l'utilisateur et application du suid bit au fichier), en revanche, avec "sudo", on peut autoriser un utilisateur à exécuter la commande date avec les droits root et donc l'autoriser à changer l'heure du système.
27/10/2014, 15h08
Sve@r

Citation:

Envoyé par nesswaw

Est-il possible de donner des droits d'accès à un user non root afin de changer la date/heure grâce à la commande date ?

Bonjour
Si tu veux bien comprendre ton OS, il te faut alors être précis. Déjà donc les droits ne s'appliquent jamais aux users mais aux fichiers. Ainsi donc, un user n'a pas d'autre droit que celui d'exister.

Ce qui se passe, en revanche, quand un user commence une intéraction avec un fichier (lequel fichier possède des droits d'accès), c'est que l'OS compare les droits donnés au fichier par rapport à celui qui tente l'accès. Et si les droits l'y autorisent alors l'OS autorise l'action demandée. Avec une exception si l'user a un uid à 0. Dans ce cas exceptionnel, l'OS ne vérifie pas les droits.

Toutefois une intéraction avec un fichier ne peut se faire que par l'intermédiaire d'une commande. Par exemple un cp fic1 fic2 tente de lire fic1 et d'écrire un fichier fic2 par la commande cp. Or la commande cp possède elle-aussi des droits d'accès ainsi qu'un propriétaire X et un groupe Y. Généralement cela ne change rien ; les droits sont vérifiés par rapport au user qui lance la commande et non à l'user propriétaire de la commande ; sauf dans un cas très particulier quand ladite commande possède un setuid (il apparait un petit "s" à la place du "x" dans le ls -l). Dans ce cas très particulier, le processus qui est lancé par la commande prend alors l'appartenance du propriétaire de la commande et non plus l'appartenance du user qui l'invoque. Et donc dans ce cas très particulier, l'accès au fichier est alors vérifié par rapport au propriétaire de la commande et non plus par rapport à l'appelant de la commande.
On trouve très peu de commandes ayant un setuid. A froid comme ça je peux citer /bin/su, /bin/sudo. On en trouve au total une dizaine.
Le même mécanisme existe aussi avec le setgid qui donne à l'appelant le gid du gid de la commande. Et dans 99% des cas, la commande appartient à root (quitte à changer de uid, autant prendre le best-of).

Donc si ta commande /bin/date a un setuid, et si elle appartient à root, alors quiconque l'exécute lancera son processus sous le compte root et non sous le sien et pourra alors modifier l'heure système.
Pour mettre un setuid sur une comande, il faut déjà être celui a qui appartient la commande (normal, seul le propriétire d'un fichier peut lui donner ou lui enlever des droits) et exécuter l'action suivante: chmod u+s commande ou bien, en mode octal, chmod 4XYZ commande (le XYZ étant les chiffres habituels du chmod classique).
Même méthode pour un gid mais ce sera "g+s" ou bien "2XYZ".

Ceci dit, question sécurité, ce n'est pas conseillé car, comme tu le vois, tu ne peux pas cibler un user particulier. Si ta commande /bin/date possède un setuid, alors ce sont tous les user qui l'exécuteront qui auront les privilèges de root sur cette commande.
Mieux vaut donc que ton user passe par un su -c date (il lui faut alors connaitre le mot de passe root) ou un sudo date (tu peux configurer qui a le droit d'appeler sudo) plutôt que d'autoriser tout le monde à lancer la commande date sous le compte de root...
27/10/2014, 17h48
jlliagre

Citation:

Envoyé par Sve@r

Si tu veux bien comprendre ton OS, il te faut alors être précis. Déjà donc les droits ne s'appliquent jamais aux users mais aux fichiers. Ainsi donc, un user n'a pas d'autre droit que celui d'exister.

Il existe cependant sous Linux les "capabilities" qui permettent d'accorder à des utilisateurs non root des privilèges spécifiques, par exemple dans ce cas précis, la capability souhaitée est CAP_SYS_TIME. C'est plus complexe à mettre en oeuvre que sudo, c'est pourquoi j'ai préféré ne conseiller cette dernière approche.

Citation:

Ceci dit, question sécurité, ce n'est pas conseillé car, comme tu le vois, tu ne peux pas cibler un user particulier. Si ta commande /bin/date possède un setuid, alors ce sont tous les user qui l'exécuteront qui auront les privilèges de root sur cette commande.

Oui mais tu peux copier la commande date dans un répertoire qui n'est accessible que par l'utilisateur ciblé et lui mettre le bit setuid de root. C'est du bricolage mais ça marche aussi.
28/10/2014, 13h06
Sve@r

Citation:

Envoyé par jlliagre

Oui mais tu peux copier la commande date dans un répertoire qui n'est accessible que par l'utilisateur ciblé et lui mettre le bit setuid de root. C'est du bricolage mais ça marche aussi.

Oui. J'y avais pas pensé mais c'est possible.
Attention toutefois que certains FS (par exemple le FS qui contient /home) sont montés avec l'option "nosuid" dans /etc/fstab (c'est par exemple le cas chez-moi). Dans ce cas, pas de setuid possible sur les fichiers de ce FS.
On peut même rajouter aussi l'option "noexec" (pour les environnements paranoiaques)...;)