Comment mettre =c3=a0 jour un fichier appartenant =c3=a0 l'utilisateur root avec cron =3f
9 réponses
G2PC
Comment mettre à jour un fichier appartenant à l'utilisateur root avec
cron ?
Bonjour, je cherche à mettre à jour le fichier deny.hosts proposé par
securityinfo, chaque semaine.
Je pourrais le faire en utilisant une tache cron, avec l'utilisateur root.
Je ne sais pas si c'est la meilleur façon de faire, utiliser root pour
lancer une tache cron, pour télécharger un fichier qui appartiendra à
root:root par défaut.
Faudrait t'il utiliser un autre utilisateur, sudoers ?
Ou encore, un simple utilisateur, avec des droits particuliers pouvant
écrire ce fichier deny.hosts (qui appartient à root:root par défaut ?
Comment feriez vous ?
Au plus simple, utiliser une tâche cron avec l'utilisateur root semble
rapide et fonctionnel, mais, est ce le plus adapté en ce qui concerne la
sécurité et les bonnes pratiques ?
Comment mettre à jour un fichier appartenant à l'utilisateur ro ot avec cron ?
... En créant un crontab sous le compte root. # crontab -e
Pierre Malard
--Apple-Mail=_263CDBA0-59E8-4600-83B9-0757A6DE42F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ouahh, que de bonnes questions !
Le 6 mai 2020 à 17:14, G2PC a écrit : Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ? Bonjour, je cherche à mettre à jour le fichier deny.hosts proposé par securityinfo, chaque semaine. Je pourrais le faire en utilisant une tache cron, avec l'utilisateur root. Je ne sais pas si c'est la meilleur façon de faire, utiliser root pour lancer une tache cron, pour télécharger un fichier qui appartiendra à root:root par défaut. Faudrait t'il utiliser un autre utilisateur, sudoers ? Ou encore, un simple utilisateur, avec des droits particuliers pouvant écrire ce fichier deny.hosts (qui appartient à root:root par défaut ? Comment feriez vous ? Au plus simple, utiliser une tâche cron avec l'utilisateur root semble rapide et fonctionnel, mais, est ce le plus adapté en ce qui concerne la sécurité et les bonnes pratiques ?
Effectivement, il y a des questions à se poser quand on utiliser l’utilisateur « root ». Mais là, dans ce cas, si je comprends bien tu cherche à modifier un fichier « système » qui appartient effectivement à … « root » avec un script que tu lanceras de ce même serveur à partir d’un appel système géré par … « root » (cron) pour contraindre les accès à ton serveur. Donc, dans ce cas précis et si ton script est bien écrit et n’ouvre pas trop les vannes (umask, droits d’exécution, …) je ne vois aucune contre-indication à le lancer « root ». Si tu veux mettre ceinture et bretelles, test dans ton script que c’est bien le processus de gestion des CRON qui appelle ton script… Donc, pour résumer, voici ce que je ferais : - script ayant les droits de root soit par héritage sudo, soit directement sur l’ID appelant. Vérification que le pèr e d’appel du script est bien « cron ». - exécution du script dans le /etc/cron.d avec les droits de root Bonne soirée -- Pierre Malard « Les utopies ne sont souvent que des vérités prématurées » Alphonse de Lamartine | _,,,---,,_ /,`.-'`' -. ;-;;,_ |,4- ) )-,_. , ( `'-' '---''(_/--' `-'_) πr perl -e '$_=q#: 3| 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-. ;-;;,_: |,A- ) )-,_. , ( `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"' `-'"'"'_): 24πr::#;y#:#n#;s#(D)(d+)#$1x$2#ge;print' - --> Ce message n’engage que son auteur <-- --Apple-Mail=_263CDBA0-59E8-4600-83B9-0757A6DE42F2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 Comment: GPGTools - http://gpgtools.org iQIzBAEBCgAdFiEE0KHTJ+AWKhmI+acm/pSWHuad/BgFAl6y2vIACgkQ/pSWHuad /BiXww//Vq0tJ0xW2c+jbb2nN8kEcONd3ZbElNDZH5TtL/pCWCZdefE/Y7Ilj/0g A17gQ6XP37g1nE+N7822iT6B9Xl0hHOuWSeJ5HgQ7pXbivRCtzwCuXqyMR1JgkYP Pv9qCigqP42dQS335FPWHPeMBbSmCmd0AXDI6+ZlASIZsXlAHCugD3CMGnEzn/jR ykb2qmKPb/2JOGNsiWtxncMmij+rkjtFf/w+jQ9XzFaFBu1gdXNGbt0d4wsBIP3C cZ8JOyXXQ8s8q+lubgctjVryfy2/p5BhJlFl6UouQcrcVLxsbhflynIgewhTR8Cq PXn0heUpxZpKtE9oYpA8UNP5rJMEuTIG9RmiWhlRfDyu6PyUflJ/rH8+/ChFD8q+ eyz1DO/Pq0Qw4Pd+QB89mVT5HuJ5eP4mmzzC1svfrtmlgEgGCAj95o7bD8M45zik PfOysUDplXSfzmxZ1IsB0LIN2mY4YIObLRWct2v8At/7luDvpLLxue6ITpFYVGoe hIclWYp4Fey4rjIHl6av40h4NHcyiLAKDycFZBlzyg2fCnkVhVLOqWtnANhMiroT DsmQnivh8ahrBGwpPaDFcW016fkfJQyp7JmCq4vOl5uCaAnylCUvcwqJesFw084F EOAROe0ph+LR+K+YJNbL9/ULG1MNcjkmGPQKIGJWxeNAQ+K3n6A =K4lC -----END PGP SIGNATURE----- --Apple-Mail=_263CDBA0-59E8-4600-83B9-0757A6DE42F2--
Le 6 mai 2020 à 17:14, G2PC <g2pc@visionduweb.com> a écrit :
Comment mettre à jour un fichier appartenant à l'utilisateur root avec
cron ?
Bonjour, je cherche à mettre à jour le fichier deny.hosts proposé par
securityinfo, chaque semaine.
Je pourrais le faire en utilisant une tache cron, avec l'utilisateur root.
Je ne sais pas si c'est la meilleur façon de faire, utiliser root pour
lancer une tache cron, pour télécharger un fichier qui appartiendra à
root:root par défaut.
Faudrait t'il utiliser un autre utilisateur, sudoers ?
Ou encore, un simple utilisateur, avec des droits particuliers pouvant
écrire ce fichier deny.hosts (qui appartient à root:root par défaut ?
Comment feriez vous ?
Au plus simple, utiliser une tâche cron avec l'utilisateur root semble
rapide et fonctionnel, mais, est ce le plus adapté en ce qui concerne la
sécurité et les bonnes pratiques ?
Effectivement, il y a des questions à se poser quand on utiliser
l’utilisateur « root ». Mais là, dans ce cas, si je comprends bien
tu cherche à modifier un fichier « système » qui appartient
effectivement à … « root » avec un script que tu lanceras de ce même
serveur à partir d’un appel système géré par … « root » (cron) pour
contraindre les accès à ton serveur.
Donc, dans ce cas précis et si ton script est bien écrit et n’ouvre
pas trop les vannes (umask, droits d’exécution, …) je ne vois aucune
contre-indication à le lancer « root ».
Si tu veux mettre ceinture et bretelles, test dans ton script que
c’est bien le processus de gestion des CRON qui appelle ton script…
Donc, pour résumer, voici ce que je ferais :
- script ayant les droits de root soit par héritage sudo, soit
directement sur l’ID appelant. Vérification que le pèr e d’appel
du script est bien « cron ».
- exécution du script dans le /etc/cron.d avec les droits de root
Bonne soirée
--
Pierre Malard
« Les utopies ne sont souvent que des vérités prématurées »
Alphonse de Lamartine
| _,,,---,,_
/,`.-'`' -. ;-;;,_
|,4- ) )-,_. , ( `'-'
'---''(_/--' `-'_) πr
perl -e '$_=q#: 3| 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-. ;-;;,_: |,A- ) )-,_. , ( `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"' `-'"'"'_): 24πr::#;y#:#n#;s#(D)(d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--
--Apple-Mail=_263CDBA0-59E8-4600-83B9-0757A6DE42F2
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP
--Apple-Mail=_263CDBA0-59E8-4600-83B9-0757A6DE42F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ouahh, que de bonnes questions !
Le 6 mai 2020 à 17:14, G2PC a écrit : Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ? Bonjour, je cherche à mettre à jour le fichier deny.hosts proposé par securityinfo, chaque semaine. Je pourrais le faire en utilisant une tache cron, avec l'utilisateur root. Je ne sais pas si c'est la meilleur façon de faire, utiliser root pour lancer une tache cron, pour télécharger un fichier qui appartiendra à root:root par défaut. Faudrait t'il utiliser un autre utilisateur, sudoers ? Ou encore, un simple utilisateur, avec des droits particuliers pouvant écrire ce fichier deny.hosts (qui appartient à root:root par défaut ? Comment feriez vous ? Au plus simple, utiliser une tâche cron avec l'utilisateur root semble rapide et fonctionnel, mais, est ce le plus adapté en ce qui concerne la sécurité et les bonnes pratiques ?
Effectivement, il y a des questions à se poser quand on utiliser l’utilisateur « root ». Mais là, dans ce cas, si je comprends bien tu cherche à modifier un fichier « système » qui appartient effectivement à … « root » avec un script que tu lanceras de ce même serveur à partir d’un appel système géré par … « root » (cron) pour contraindre les accès à ton serveur. Donc, dans ce cas précis et si ton script est bien écrit et n’ouvre pas trop les vannes (umask, droits d’exécution, …) je ne vois aucune contre-indication à le lancer « root ». Si tu veux mettre ceinture et bretelles, test dans ton script que c’est bien le processus de gestion des CRON qui appelle ton script… Donc, pour résumer, voici ce que je ferais : - script ayant les droits de root soit par héritage sudo, soit directement sur l’ID appelant. Vérification que le pèr e d’appel du script est bien « cron ». - exécution du script dans le /etc/cron.d avec les droits de root Bonne soirée -- Pierre Malard « Les utopies ne sont souvent que des vérités prématurées » Alphonse de Lamartine | _,,,---,,_ /,`.-'`' -. ;-;;,_ |,4- ) )-,_. , ( `'-' '---''(_/--' `-'_) πr perl -e '$_=q#: 3| 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-. ;-;;,_: |,A- ) )-,_. , ( `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"' `-'"'"'_): 24πr::#;y#:#n#;s#(D)(d+)#$1x$2#ge;print' - --> Ce message n’engage que son auteur <-- --Apple-Mail=_263CDBA0-59E8-4600-83B9-0757A6DE42F2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 Comment: GPGTools - http://gpgtools.org iQIzBAEBCgAdFiEE0KHTJ+AWKhmI+acm/pSWHuad/BgFAl6y2vIACgkQ/pSWHuad /BiXww//Vq0tJ0xW2c+jbb2nN8kEcONd3ZbElNDZH5TtL/pCWCZdefE/Y7Ilj/0g A17gQ6XP37g1nE+N7822iT6B9Xl0hHOuWSeJ5HgQ7pXbivRCtzwCuXqyMR1JgkYP Pv9qCigqP42dQS335FPWHPeMBbSmCmd0AXDI6+ZlASIZsXlAHCugD3CMGnEzn/jR ykb2qmKPb/2JOGNsiWtxncMmij+rkjtFf/w+jQ9XzFaFBu1gdXNGbt0d4wsBIP3C cZ8JOyXXQ8s8q+lubgctjVryfy2/p5BhJlFl6UouQcrcVLxsbhflynIgewhTR8Cq PXn0heUpxZpKtE9oYpA8UNP5rJMEuTIG9RmiWhlRfDyu6PyUflJ/rH8+/ChFD8q+ eyz1DO/Pq0Qw4Pd+QB89mVT5HuJ5eP4mmzzC1svfrtmlgEgGCAj95o7bD8M45zik PfOysUDplXSfzmxZ1IsB0LIN2mY4YIObLRWct2v8At/7luDvpLLxue6ITpFYVGoe hIclWYp4Fey4rjIHl6av40h4NHcyiLAKDycFZBlzyg2fCnkVhVLOqWtnANhMiroT DsmQnivh8ahrBGwpPaDFcW016fkfJQyp7JmCq4vOl5uCaAnylCUvcwqJesFw084F EOAROe0ph+LR+K+YJNbL9/ULG1MNcjkmGPQKIGJWxeNAQ+K3n6A =K4lC -----END PGP SIGNATURE----- --Apple-Mail=_263CDBA0-59E8-4600-83B9-0757A6DE42F2--
Cyrille BIOT
Bsr, Si tout appartient à root, je pense que le plus simple est d'utiliser simplement la crontab root. Mais ce n'est que mon avis... Mais pourquoi faire simple quand on peut faire compliqué.... Ou l'inverse, je ne sais plus trop... ;) Cdt Cyrille
Bsr,
Si tout appartient à root, je pense que le plus simple est d'utiliser
simplement la crontab root.
Mais ce n'est que mon avis... Mais pourquoi faire simple quand on peut
faire compliqué.... Ou l'inverse, je ne sais plus trop... ;)
Cdt
Cyrille
Bsr, Si tout appartient à root, je pense que le plus simple est d'utiliser simplement la crontab root. Mais ce n'est que mon avis... Mais pourquoi faire simple quand on peut faire compliqué.... Ou l'inverse, je ne sais plus trop... ;) Cdt Cyrille
Étienne Mollier
--tKW2IUtsqtDRztdT Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Bonjour, J'ai juste quelque remarques à deux sous. G2PC, on 2020-05-08 07:35:17 +0200:
Concernant le script, ce serait celui la, il n'est pas spécialement problématique, bon, tout de même QUATRE lignes. Je suppose que je peux de ce faire le lancer directement depuis le crontab de root, mais, un script de 4 lignes ce sera mieux.
Un script de quatre lignes, même s'il est court et peut être tapé à la main, ça fait beaucoup de ligne à taper s'il doit être exécuté fréquemment. Donc cron reste bienvenu.
cd /etc
Peut-être que ce serait bien de remplacer la commande:
sudo mv hosts.deny hosts.deny.bak
^^ par: $ sudo cp hosts.deny hosts.deny.bak ^^ Sinon le fichier /etc/hosts.deny n'existe plus sur la machine pendant le temps du téléchargement, ce qui pourrait laisser les portes ouvertes aux vils pirates de tout poils pendant cet interval de temps, fut-il juste de quelque millisecondes.
Éventuellement, si vous ne faites pas confiance à wget, parce que cette commande intéragit avec l'extérieur, il est possible de récupérer le fichier en tant qu'un utilisateur normal, éventuellement créé spécifiquement pour cette tâch e ; ça fait partie d'un éventuelle stratégie qui consisterait à « a ffiner les droits » :) $ wget https://hosts.ubuntu101.co.za/superhosts.deny -P /tmp Du coup la commande suivante
sudo mv superhosts.deny hosts.deny
deviendrait : $ sudo mv /tmp/superhosts.deny hosts.deny Tout cela suppose que vous faites confiance au service délivré par hosts.ubuntu101.co.za pour ne pas mettre n'importe quoi dans votre /etc/hosts.deny, cat ils seraient en position de rendre votre machine inaccessible en mettant l'Internet complet dans ce fichier. Amicalement, -- Étienne Mollier Fingerprint: 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d Help find cures against the Covid-19 ! Give CPU cycles: * : https://boinc.bakerlab.org/rosetta/ * : https://foldingathome.org/ --tKW2IUtsqtDRztdT Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEiWj4FzqNZS4rFmXPZAyZDOTALZsFAl61Cd0ACgkQZAyZDOTA LZsFjwv+POsnmg2CqrhdU7ury+/aAxnghmjGjOuRCZg0tBwPge4JdSMfUWTwbtbI 4ylvEUQO4KCX2qJCbW2KxNXaVsJZRuc1G3qSLumVl4XUh7sWsrg0YSMjVbWRJQ7f wZ2J+9t54WZ6OyGpvqpIh0I5M+/xfHerkwuz9tPRcAnFzQvwaxGNFvfOlELQ/O5K iw/i8NWa7daGNsTVWJEGqDo63TnM6Vt/T7EaU6WyUVyrRaERLIaxddEa3VmZG6cL VhRHnXn+zKgR0QLwsyIzfzhz5EWj9IkEo+SvnLr0KURiYn0dThkJyWwYMKdAmtdG VtCtlnik446XHT3nfIZHtMfLr/aY6kVyqXjMIY3NK2e3qGViJ6WnCJfD2Y8HdiOO GtRQ+lMvDBHllKn0DaNFyw2ARgE7jtO5scSTUGfIHxj4kuX1d6YCA1thkA9Hz9oM 1VLYnNNeshOw5kam7URkrndmByS30PMB8IfYdW2PAsAsEg2UTLD0OX9AUNfLg7eK BZiyytGk =kfDk -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT--
Concernant le script, ce serait celui la, il n'est pas spécialement
problématique, bon, tout de même QUATRE lignes.
Je suppose que je peux de ce faire le lancer directement depuis le
crontab de root, mais, un script de 4 lignes ce sera mieux.
Un script de quatre lignes, même s'il est court et peut être
tapé à la main, ça fait beaucoup de ligne à taper s'il doit être
exécuté fréquemment. Donc cron reste bienvenu.
cd /etc
Peut-être que ce serait bien de remplacer la commande:
sudo mv hosts.deny hosts.deny.bak
^^
par:
$ sudo cp hosts.deny hosts.deny.bak
^^
Sinon le fichier /etc/hosts.deny n'existe plus sur la machine
pendant le temps du téléchargement, ce qui pourrait laisser les
portes ouvertes aux vils pirates de tout poils pendant cet
interval de temps, fut-il juste de quelque millisecondes.
Éventuellement, si vous ne faites pas confiance à wget, parce
que cette commande intéragit avec l'extérieur, il est possible
de récupérer le fichier en tant qu'un utilisateur normal,
éventuellement créé spécifiquement pour cette tâch e ; ça fait
partie d'un éventuelle stratégie qui consisterait à « a ffiner
les droits » :)
Tout cela suppose que vous faites confiance au service délivré
par hosts.ubuntu101.co.za pour ne pas mettre n'importe quoi dans
votre /etc/hosts.deny, cat ils seraient en position de rendre
votre machine inaccessible en mettant l'Internet complet dans ce
fichier.
Amicalement,
--
Étienne Mollier <etienne.mollier@mailoo.org>
Fingerprint: 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d
Help find cures against the Covid-19 ! Give CPU cycles:
* Rosetta@home: https://boinc.bakerlab.org/rosetta/
* Folding@home: https://foldingathome.org/
--tKW2IUtsqtDRztdT Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Bonjour, J'ai juste quelque remarques à deux sous. G2PC, on 2020-05-08 07:35:17 +0200:
Concernant le script, ce serait celui la, il n'est pas spécialement problématique, bon, tout de même QUATRE lignes. Je suppose que je peux de ce faire le lancer directement depuis le crontab de root, mais, un script de 4 lignes ce sera mieux.
Un script de quatre lignes, même s'il est court et peut être tapé à la main, ça fait beaucoup de ligne à taper s'il doit être exécuté fréquemment. Donc cron reste bienvenu.
cd /etc
Peut-être que ce serait bien de remplacer la commande:
sudo mv hosts.deny hosts.deny.bak
^^ par: $ sudo cp hosts.deny hosts.deny.bak ^^ Sinon le fichier /etc/hosts.deny n'existe plus sur la machine pendant le temps du téléchargement, ce qui pourrait laisser les portes ouvertes aux vils pirates de tout poils pendant cet interval de temps, fut-il juste de quelque millisecondes.
Éventuellement, si vous ne faites pas confiance à wget, parce que cette commande intéragit avec l'extérieur, il est possible de récupérer le fichier en tant qu'un utilisateur normal, éventuellement créé spécifiquement pour cette tâch e ; ça fait partie d'un éventuelle stratégie qui consisterait à « a ffiner les droits » :) $ wget https://hosts.ubuntu101.co.za/superhosts.deny -P /tmp Du coup la commande suivante
sudo mv superhosts.deny hosts.deny
deviendrait : $ sudo mv /tmp/superhosts.deny hosts.deny Tout cela suppose que vous faites confiance au service délivré par hosts.ubuntu101.co.za pour ne pas mettre n'importe quoi dans votre /etc/hosts.deny, cat ils seraient en position de rendre votre machine inaccessible en mettant l'Internet complet dans ce fichier. Amicalement, -- Étienne Mollier Fingerprint: 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d Help find cures against the Covid-19 ! Give CPU cycles: * : https://boinc.bakerlab.org/rosetta/ * : https://foldingathome.org/ --tKW2IUtsqtDRztdT Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEiWj4FzqNZS4rFmXPZAyZDOTALZsFAl61Cd0ACgkQZAyZDOTA LZsFjwv+POsnmg2CqrhdU7ury+/aAxnghmjGjOuRCZg0tBwPge4JdSMfUWTwbtbI 4ylvEUQO4KCX2qJCbW2KxNXaVsJZRuc1G3qSLumVl4XUh7sWsrg0YSMjVbWRJQ7f wZ2J+9t54WZ6OyGpvqpIh0I5M+/xfHerkwuz9tPRcAnFzQvwaxGNFvfOlELQ/O5K iw/i8NWa7daGNsTVWJEGqDo63TnM6Vt/T7EaU6WyUVyrRaERLIaxddEa3VmZG6cL VhRHnXn+zKgR0QLwsyIzfzhz5EWj9IkEo+SvnLr0KURiYn0dThkJyWwYMKdAmtdG VtCtlnik446XHT3nfIZHtMfLr/aY6kVyqXjMIY3NK2e3qGViJ6WnCJfD2Y8HdiOO GtRQ+lMvDBHllKn0DaNFyw2ARgE7jtO5scSTUGfIHxj4kuX1d6YCA1thkA9Hz9oM 1VLYnNNeshOw5kam7URkrndmByS30PMB8IfYdW2PAsAsEg2UTLD0OX9AUNfLg7eK BZiyytGk =kfDk -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT--
l0f4r0
Bonjour, 8 mai 2020 à 07:35 de :
Concernant le script, ce serait celui la, il n'est pas spécialemen t problématique, bon, tout de même QUATRE lignes. Je suppose que je peux de ce faire le lancer directement depuis le cr ontab de root, mais, un script de 4 lignes ce sera mieux. cd /etc sudo mv hosts.deny hosts.deny.bak sudo wget > https://hosts.ubuntu101.co.za/superhosts.deny> sudo mv superhosts.deny hosts.deny
A ma connaissance, si tu pars sur la piste d'un script setuidé root ou d'une crontab root, tu peux virer les "sudo". Si tu pars plutôt sur un utilisateur sudoer, alors je pense que sauf d irective "NOPASSWD" dans le fichier /etc/sudoers tu vas perdre toute possib ilité de programmation laissée sans surveillance (type crontab us er) à cause de l'interactivité requise pour sudo (demande du mot de passe). Bien cordialement, l0f4r0
Bonjour,
8 mai 2020 à 07:35 de g2pc@visionduweb.com:
Concernant le script, ce serait celui la, il n'est pas spécialemen t problématique, bon, tout de même QUATRE lignes.
Je suppose que je peux de ce faire le lancer directement depuis le cr ontab de root, mais, un script de 4 lignes ce sera mieux.
A ma connaissance, si tu pars sur la piste d'un script setuidé root ou d'une crontab root, tu peux virer les "sudo".
Si tu pars plutôt sur un utilisateur sudoer, alors je pense que sauf d irective "NOPASSWD" dans le fichier /etc/sudoers tu vas perdre toute possib ilité de programmation laissée sans surveillance (type crontab us er) à cause de l'interactivité requise pour sudo (demande du mot de passe).
Concernant le script, ce serait celui la, il n'est pas spécialemen t problématique, bon, tout de même QUATRE lignes. Je suppose que je peux de ce faire le lancer directement depuis le cr ontab de root, mais, un script de 4 lignes ce sera mieux. cd /etc sudo mv hosts.deny hosts.deny.bak sudo wget > https://hosts.ubuntu101.co.za/superhosts.deny> sudo mv superhosts.deny hosts.deny
A ma connaissance, si tu pars sur la piste d'un script setuidé root ou d'une crontab root, tu peux virer les "sudo". Si tu pars plutôt sur un utilisateur sudoer, alors je pense que sauf d irective "NOPASSWD" dans le fichier /etc/sudoers tu vas perdre toute possib ilité de programmation laissée sans surveillance (type crontab us er) à cause de l'interactivité requise pour sudo (demande du mot de passe). Bien cordialement, l0f4r0
1) Tu gagnerais en flexibilité/rapidité/lisibilité à mo difier tes : cmd1 >>/etc/hosts cmd2 >>/etc/hosts cmdX >>/etc/hosts en : { cmd1 cmd2 cmdX } >>/etc/hosts 2) C'est pas optimal en effet de se baser sur les numéros de lignes po ur ton sed... Peut-être le plus simple serait de ne pas ajouter à la base ces l ignes doublons depuis le fichier téléchargé avec un truc du genre : grep -vf /etc/hosts /tmp/hosts >>/etc/hosts NB : la commande marche mais je t'invite à vérifier qu'il n'y a p as d'effet de bord en pratique. Il est possible qu'il faille être un p eu plus fin... Bien cordialement, l0f4r0
2) C'est pas optimal en effet de se baser sur les numéros de lignes po ur ton sed...
Peut-être le plus simple serait de ne pas ajouter à la base ces l ignes doublons depuis le fichier téléchargé avec un truc du genre :
grep -vf /etc/hosts /tmp/hosts >>/etc/hosts
NB : la commande marche mais je t'invite à vérifier qu'il n'y a p as d'effet de bord en pratique. Il est possible qu'il faille être un p eu plus fin...
1) Tu gagnerais en flexibilité/rapidité/lisibilité à mo difier tes : cmd1 >>/etc/hosts cmd2 >>/etc/hosts cmdX >>/etc/hosts en : { cmd1 cmd2 cmdX } >>/etc/hosts 2) C'est pas optimal en effet de se baser sur les numéros de lignes po ur ton sed... Peut-être le plus simple serait de ne pas ajouter à la base ces l ignes doublons depuis le fichier téléchargé avec un truc du genre : grep -vf /etc/hosts /tmp/hosts >>/etc/hosts NB : la commande marche mais je t'invite à vérifier qu'il n'y a p as d'effet de bord en pratique. Il est possible qu'il faille être un p eu plus fin... Bien cordialement, l0f4r0
l0f4r0
8 mai 2020 à 18:20 de :
https://wiki.visionduweb.fr/index.php?title=Sommaire_S%C3%A9curit%C 3%A9#Mettre_.C3.A0_jour_le_fichier_.2Fetc.2Fhosts_automatiquement_tous_les_ mois
...et j'oubliais, également remplacer les : echo "X" echo "Y" echo "Z" en : cat <<'EOF' X Y Z EOF Bien cordialement, l0f4r0
8 mai 2020 à 18:20 de g2pc@visionduweb.com:
> https://wiki.visionduweb.fr/index.php?title=Sommaire_S%C3%A9curit%C 3%A9#Mettre_.C3.A0_jour_le_fichier_.2Fetc.2Fhosts_automatiquement_tous_les_ mois
https://wiki.visionduweb.fr/index.php?title=Sommaire_S%C3%A9curit%C 3%A9#Mettre_.C3.A0_jour_le_fichier_.2Fetc.2Fhosts_automatiquement_tous_les_ mois
...et j'oubliais, également remplacer les : echo "X" echo "Y" echo "Z" en : cat <<'EOF' X Y Z EOF Bien cordialement, l0f4r0
Sébastien NOBILI
Bonjour, Le 2020-05-09 12:46, G2PC a écrit :
# Utiliser le lien direct vers le fichier superhosts.deny (Plus de 15Mo) : https://hosts.ubuntu101.co.za/superhosts.deny cd /etc sudo cp hosts.deny hosts.deny.bak
J'éviterais ce type de construction (changement de dossier puis copie avec des noms relatifs). Il risque d'arriver un jour où tu ajouteras/modifieras/supprimeras une ligne qui fera que la copie relative ne se fera plus depuis le bon endroit. Je privilégierais ça : sudo cp /etc/hosts.deny /etc/hosts.deny.bak
# On peut télécharger le fichier dans le répertoire /tmp en tant que simple utilisateur : wget https://hosts.ubuntu101.co.za/superhosts.deny -P /tmp
Tu devrais interrompre ici si wget n'aboutit pas : wget https://hosts.ubuntu101.co.za/superhosts.deny -P /tmp || exit 1
cat /tmp/superhosts.deny >> /etc/hosts.deny
Chevron simple (">") plutôt non ? tu veux remplacer le contenu plutôt que l'ajouter à la suite (si j'ai bien suivi)… Sébastien
Bonjour,
Le 2020-05-09 12:46, G2PC a écrit :
# Utiliser le lien direct vers le fichier superhosts.deny (Plus de
15Mo) : https://hosts.ubuntu101.co.za/superhosts.deny
cd /etc
sudo cp hosts.deny hosts.deny.bak
J'éviterais ce type de construction (changement de dossier puis copie
avec des
noms relatifs). Il risque d'arriver un jour où tu
ajouteras/modifieras/supprimeras
une ligne qui fera que la copie relative ne se fera plus depuis le bon
endroit.
Je privilégierais ça :
sudo cp /etc/hosts.deny /etc/hosts.deny.bak
# On peut télécharger le fichier dans le répertoire /tmp en tant
que simple utilisateur :
wget https://hosts.ubuntu101.co.za/superhosts.deny -P /tmp
Tu devrais interrompre ici si wget n'aboutit pas :
# Utiliser le lien direct vers le fichier superhosts.deny (Plus de 15Mo) : https://hosts.ubuntu101.co.za/superhosts.deny cd /etc sudo cp hosts.deny hosts.deny.bak
J'éviterais ce type de construction (changement de dossier puis copie avec des noms relatifs). Il risque d'arriver un jour où tu ajouteras/modifieras/supprimeras une ligne qui fera que la copie relative ne se fera plus depuis le bon endroit. Je privilégierais ça : sudo cp /etc/hosts.deny /etc/hosts.deny.bak
# On peut télécharger le fichier dans le répertoire /tmp en tant que simple utilisateur : wget https://hosts.ubuntu101.co.za/superhosts.deny -P /tmp
Tu devrais interrompre ici si wget n'aboutit pas : wget https://hosts.ubuntu101.co.za/superhosts.deny -P /tmp || exit 1
cat /tmp/superhosts.deny >> /etc/hosts.deny
Chevron simple (">") plutôt non ? tu veux remplacer le contenu plutôt que l'ajouter à la suite (si j'ai bien suivi)… Sébastien
Sébastien NOBILI
Le 2020-05-09 15:17, G2PC a écrit :
Ce qui nous donne, pour le moment, deux script différents, un que j'utilise manuellement, un second qui serait à lancer via la crontab de root. Je me trompe, ou, ils ne seront pas pareil, du fait de l'approche avec root, qui serait différente que dans le cas d'un utilisateur normal mais en sudoers ?
Je n'ai pas regardé en détail la différence entre les deux, mais je pense que tu fais fausse route. Peu importe la façon dont il va être lancé, il est préférable de n'avoir qu'un seul script (qui pourra éventuellement s'adapter à son contexte d'exécution). Là encore, il arrivera sûrement un jour où tu feras une modification dans l'un et que tu oublieras de reporter dans l'autre et ce sera le drame. Sébastien
Le 2020-05-09 15:17, G2PC a écrit :
Ce qui nous donne, pour le moment, deux script différents, un que
j'utilise manuellement, un second qui serait à lancer via la crontab
de root.
Je me trompe, ou, ils ne seront pas pareil, du fait de l'approche avec
root, qui serait différente que dans le cas d'un utilisateur normal
mais en sudoers ?
Je n'ai pas regardé en détail la différence entre les deux, mais je
pense
que tu fais fausse route. Peu importe la façon dont il va être lancé, il
est préférable de n'avoir qu'un seul script (qui pourra éventuellement
s'adapter à son contexte d'exécution).
Là encore, il arrivera sûrement un jour où tu feras une modification
dans
l'un et que tu oublieras de reporter dans l'autre et ce sera le drame.
Ce qui nous donne, pour le moment, deux script différents, un que j'utilise manuellement, un second qui serait à lancer via la crontab de root. Je me trompe, ou, ils ne seront pas pareil, du fait de l'approche avec root, qui serait différente que dans le cas d'un utilisateur normal mais en sudoers ?
Je n'ai pas regardé en détail la différence entre les deux, mais je pense que tu fais fausse route. Peu importe la façon dont il va être lancé, il est préférable de n'avoir qu'un seul script (qui pourra éventuellement s'adapter à son contexte d'exécution). Là encore, il arrivera sûrement un jour où tu feras une modification dans l'un et que tu oublieras de reporter dans l'autre et ce sera le drame. Sébastien