JJD a écrit 516 commentaires

Au moins dans Gnome (paramètres, accessibilité, Assistant de saisie) on appelle ça des touches rémanentes et pas collantes…

Salut,

Ce que j'ai compris de ces deux vulnérabilités, c'est que la gravité est élevée parce que l'on peut éventuellement exécuter du code arbitraire sur le serveur, mais que cela ne concerne que des configurations spécifiques et certainement peu répandues.

La faille CVE-2021-44790 concerne le module mod_lua, qui permet d'exécuter du code en lua sur le serveur Apache. Ce module n'est normalement pas activé par défaut (au moins sous Debian) et ne doit concerner qu'un faible nombre d'installations.

De même, pour exploiter CVE-2021-44224, il faut que le serveur Apache soit configuré pour se comporter comme un proxy direct et cela ne concerne que les version 2.4.49 et 2.4.50 (les configurations où Apache sert de frontal, en reverse proxy, à des serveur d'applications ou pour du load-balancing ne sont donc pas concernées). Même si c'est bien une utilisation licite d'Apache, je pense que cela doit représenter une très faible proportion des Apache installés (pour faire ce genre de choses, il me semble que l'on prend généralement des applications spécialisées, comme squid). De plus, les serveurs proxy sont le plus souvent joignables uniquement depuis un réseau interne et/ou avec une authentification.

Je ne minimise pas le risque réel pour les serveurs ayant ce type de configuration, mais la surface d'attaque est sans commune mesure avec ce que l'on a eu pour la faille log4shell.

À+

De ce que je connais de fetchmail, je ne pense pas qu'il soit possible de lui dire de déplacer les mails récupérés dans un dossier IMAP spécifique.
En revanche, cela doit être possible avec getmail qui possède une option de configuration move_on_delete (la façon de configurer m'a un peu surpris : il faut demander la suppression des mails récupérés en indiquant que ces mails supprimés doivent être déplacés…) Évidemment, dans ce cas, le mail est déplacé au moment où on le récupère, pas après analyse et impression des pièces jointes. Pour cela, on n'échappera pas à l'utilisation d'un client IMAP (api ou cli) et ça va forcément se compliquer un peu (il faudra avoir un identifiant du mail pour savoir quoi déplacer).

Salut,

Tu peux peut-être arriver à faire ça avec un service systemd déclaré ainsi :

[Unit]
Description=Alsamixer on tty2

[Service]
Type=simple
ExecStart=/usr/bin/alsamixer
StandardInput=tty
StandardOutput=tty
TTYPath=/dev/tty2

[Install]
WantedBy=multi-user.target

Je précise que je n'ai pas testé mais honteusement pompé ça sur un forum après avoir recherché «systemd launch command in tty at startup»

Salut,

J'ai aussi essayé de générer des formulaires PDF, à partir de libreoffice, en y insérant des champs de signature vides mais il semble que ce n'est pas possible, au moins pour l'instant.

Il y a bien une demande d'amélioration sur le bugtracker, mais pas vraiment de nouvelles pour l'instant :

https://bugs.documentfoundation.org/show_bug.cgi?id=126207

Mais si quelqu'un a une solution pour faire ce genre de choses (avec libreoffice ou une autre application), je suis aussi preneur.

Sur une Debian stable, je pense que la solution qui présente le moins de risque est d'installer dino depuis buster-backports : la version 0.2.0 y est disponible.

Je comprends bien l'intérêt de tout cela mais, sans vouloir dénigrer, il ne s'agit pas vraiment d'auto-hébergement d'un système de messagerie.
Tu dépends complètement de fournisseurs externes, aussi bien pour la réception que pour l'envoi des mails et tu ne gères pas de domaine de messagerie. La création d'une BAL, avec son adresse, doit être faite chez un prestataire qui recevra les mails et les stockera jusqu'à ce que tu les récupères (ce qui lui laissera largement le temps de les analyser pour pour enrichir ses données marketing).

Salut,

je n'ai pas vraiment de réponse à tes soucis mais au moins quelques pistes de recherche…

Il faudrait regarder ce qu'il se passe sur le serveur CIFS. Est-ce un Linux avec samba ou une machine Windows ou autre chose (NAS, …) ? Quelles sont les options de montage dans /etc/fstab ?

Le groupe et le propriétaire des fichiers sont obtenus via des identifiants numériques. Ensuite, ls affiche les noms associés à ces identifiants en les récupérant dans sa base locale (/etc/passwd et /etc/group le plus souvent mais ce n'est pas systématique : voir /etc/nsswitch.conf).

Dans ton cas, pour le dossier 2020_49, il n'y a pas d'association entre l'identifiant numérique et un utilisateur, alors c'est l'id qui s'affiche.

Est-ce que ce répertoire a bien été créé par ton script, lancé par www-data, ou bien est-ce qu'il a pu être créé directement sur le serveur ?
Sur le serveur, qui en est le propriétaire ?
Au pire, il doit être possible de forcer le propriétaire apparent côté client avec l'option forceuid (et forcegid) dans fstab. Ça peut régler le problème (mais par forcément : il y aura quand même une erreur si, sur le serveur, l'utilisateur authentifié lors du montage n'a pas les droits d'écriture).

Salut,

Normalement, les commandes du et df doivent gérer correctement les liens physiques.

Imagine que tu es dans un répertoire rep avec deux sous-répertoires rep1 et rep2. Dans rep1, tu as un fichier BIG1 de 1GO et tu fais un lien sur BIG2 dans rep2 (ln rep1/BIG1 rep2/BIG2).

Pour être précis, tu n'as alors pas un fichier avec 1 lien, mais un fichier unique qui est listé dans deux répertoires différents et sous deux noms différents.

Un "df ." te donnera bien la taille des données sur le filesystem courant. Tu peux créer autant de liens physiques que tu veux, ça ne fera pas changer le résultat du df.

Un "du rep1" ou un "du rep2" t'indiqueront tous deux 1GO d'espace occupé. En revanche, un "du ." te donneras aussi 1GO et pas 2GO… au moins si tu as une version de du qui ne date pas de Mathusalem. Sur un système Linux, du fait normalement partie des GNU Core Uilities et devrait se comporter ainsi.

Cependant, sur ton NAS, il y a de grande chance que du et df soient simplement des commandes de busybox plutôt que des binaires séparés. Fais un "ls -l /usr/bin/du" pour le vérifier (tu devrais avoir un lien symbolique vers le vrai binaire). Dans ces conditions, le comportement de ces commandes dépend de la version. Mais normalement, df devrait tout de même fournir le bon résultat (il ne parcourt pas tout le disque pour sons calcul). Pour du, c'est une autre histoire, mais les versions récentes (enfin, au moins depuis 4 ans, mais certainement plus) doivent fonctionner correctement.

Si sur ton NAS, les résultats ne sont pas corrects, vérifie les versions utilisées ("du --help") : ça permettra de savoir où chercher les causes. Mais, quoi qu'il arrive, et quels que soient les résultats affichés, un lien physique ne te mangera pas de place sur ton disque.

Salut,

Le générateur d'attestation du ministère de l'intérieur ne fonctionne pas en ligne. Une fois que la page est chargée dans le navigateur, tout se passe en local : aucune requête n'est émise sur le réseau (et donc aucune information ne part vers le gouvernement, n'en déplaise aux complotistes).
J'ai testé en mettant mon téléphone en mode avion et j'ai bien pu générer le PDF avec les informations saisies.
Il faut juste penser à recharger la page de temps en temps au cas où le formulaire aurait été mis à jour.

Salut,
Dans ta vidéo, le fichier est nommé 20-intel.conf*.save* .

Essaie de renommer correctement ce fichier puis redémarre ton serveur X11 (dans le doute reboote) pour vérifier si c'est OK.

Si papa ne peut pas accéder au dossier partagé, c'est peut-être parce qu'il n'appartenait pas encore au groupe partage au moment de son ouverture de session (en tout cas, je ne vois pas d'autre raison). Refais un test avec avoir fermé et re-ouvert la session de papa.

Pour ce qui est des droits en écriture pour tous les membres du groupe, sur tous les fichiers du répertoire, je ne pense pas qu'il soit possible de faire ce que tu veux en utilisant uniquement les droits standard. Lorsque maman va créer un fichier dans le dossier partagé, son groupe sera bien partage mais il n'y aura pas les droits d'écriture pour les autres membres du groupe (sauf à modifier le masque de droits pas défaut mais c'est aléatoire et potentiellement dangereux).

Mais il est peut-être possible de s'en sortir en utilisant les ACL (acess control list). Il faudrait essayer quelque chose dans ce genre :

setfacl --default -m g:partage:rwx "Dossier partagé"

Ensuite, les fichiers créés dans le dossier partagé seront bien autorisés en écritures pour les membres de partage.
En revanche, c'est un peu plus compliqué pour les fichiers copiés ou déplacés dans le répertoire. Ils conservent les droits du fichier d'origine et je ne sais pas trop comment s'en sortir à ce niveau-là.

Si quelqu'un sait comment faire, je suis aussi preneur.

Salut,

Il existe en fait deux formats pour les fichiers crontab.

Le format que tu as utilisé sert dans les fichiers qui sont déposés dans /etc/cron.d/. Ces fichiers servent généralement à exécuter des tâches "système" (rotation des logs, tâches de maintenance, …)

Pour les fichiers utilisateurs, que tu édites avec "crontab -e" et que tu visualises avec "crontab -l", le format est très légèrement différent puisqu'on n'indique pas l'utilisateur sous lequel la commande doit être exécutée. Dans ton cas, il devrait donc suffire d'enlever "user" pour que ça fonctionne.

Avec le fichier que tu avais, le daemon crond a essayé d'exécuter la commande "user python3 …" et cela a dû générer une erreur (disant que la commande "user" n'a pas été trouvée). Cette erreur a normalement été envoyé par mail à user (via le serveur de mail local, s'il y en a un).

J'espère que tout cela est clair.

À+

Salut,

Les fichiers /etc/bashrc et ~/.bashrc sont interprétés au démarrage de bash s'il s'agit d'un shell interactif qui n'est pas un shell de connexion (login ou "su -" par exemple).

Lors du démarrage d'un shell de connexion, ce sont les fichiers /etc/profile puis ~/.bash_profile ou ~/.bash_login ou ~/.profile qui sont utilisés. Si l'on veut que les fichiers bashrc soient également lus, il faut donc inclure cette lecture dans /etc/profile ou ~/.profile (mais il me semble que c'est généralement fait dans les fichiers inclus par les distributions).

Peut-être que le fichier /etc/profile a été modifié sur ta machine et n'appelle plus /etc/bashrc.
Si ça fonctionne pour root, c'est soit parce que le fichier .profile de root appelle explicitement les fichiers bashrc, soit parce que la session root n'a pas un shell de connexion (appel avec su ou sudo sans les options "-" ou "-i")

Salut,

Je pense que ton problème vient de ces deux lignes :

listen on lo
listen on 0.0.0.0 port 25 tls pki mon_domaine.fr hostname mon_domaine.fr auth-optional

La première indique qu'il faut écouter sur l'interface locale (127.0.0.1/::1) et sur le port 25 (implicitement).
La deuxième demande l'ouverture d'une socket en écoute sur le port 25 de toutes les adresses IP disponibles, et donc y compris 127.0.0.1.

Je suppose que l'on doit pouvoir régler cela en supprimant la première ligne (lo). Si tu as besoin de paramètres différentes sur l'interface lo et les interfaces externes, il va peut-être falloir lister explicitement ces interfaces externes dans la configuration.

Je précise que je connais peu opensmtpd et que je peux être passé complètement à côté du vrai problème…

Je confirme toute l'analyse de Cyril.

Je tiens tout de même à ajouter que comme le script utilise explicitement bash (mais ça doit aussi fonctionner avec d'autres shell), on peut utiliser les mécanismes internes au shell pour avoir la longueur d'une chaine de caractères :

echo ${#LENGHT_SOURCE_TRACKER} → 39

Dans ce cas particulier, avec des chaines représentant des URL, il ne devrait pas il y avoir de souci mais si la chaine contient des caractères codés sur plusieurs octets (Utf-8), il faut faire attention à la locale courante, voire au shell utilisé (bash ou wc donneront le bon résultat si la locale est bonne mais dash, par exemple, retournera le nombre d'octets)

Enfin, concernant l'utilisation de LENGTH à la place de LENGHT dans le nom des variables, je n'ai pas d'opinion ;-)

Il est en effet possible de créer un système de fichier directement sur le disque sans y créer de partitions.

Au besoin, tu peux essayer de trouver quel système de fichiers est utilisé avec la commande suivante :
file -s /dev/sdb

Avec un peu de chance, s'il s'agit d'un système de fichier reconnu par ton noyau, tu peux même tenter de monter directement le disque :
mount /dev/sdb /mnt/panasonic

Si aucune des ces deux commandes ne fonctionnent, ça risque de devenir compliqué… D'après une recherche très rapide, il semble qu'il y ait deux possibilité : soit c'est de l'UDF (et le montage devrait être possible) soit c'est un système complètement propriétaire (et là, ça se corse).

Salut,

Tu peux aussi regarder du côté des applications alternatives. Il y en a un certain nombre sur le store Android (dont certaines open source) et au moins une sur f-droid (Gadgetbridge). À l'époque où j'avais un mi band (je l'ai perdu depuis), ces applications offraient même plus de fonctionnalités que l'application officielle.

C'est intéressant comme comportement…

Je me suis dit que cela pouvait être lié à l'absence de sendmail sur ton système. Les sorties d'erreur et standard d'une tâche cron, si elle ne sont pas redirigées, sont envoyées par mail au propriétaire du cron.

Est-ce qu'il est possible que, ce mécanisme ne fonctionnant pas, le script se plante ? De mon côté, je n'ai pas réussi à reproduire le souci (sous Debian)

Une première piste est de regarder si des choses s'affichent dans les logs système quand tu ne rediriges pas la sortie standard (fichiers syslog, message, cron dans /var/log/ ou journalctl suivant que tu utilises systemd ou pas).

Concernant la langue utilisée,je peux confirmer que dans l'environnement de cron, la langue n'est pas positionnée (variable LANG) et que c'est donc l'anglais (en pratique "C"), qui est utilisée.
Pour éviter cela, on peut positionner la variable dans le script (export LANG=fr_FR.UTF-8) si cela est nécessaire mais, à mon avis, il est préférable de mettre la date sous un format de type AAAAMMJJ (ce qui permet en plus le classement des fichiers produits).

Sur la question du fichier tar vide, il faudrait un peu plus de détails. La commande tar, telle que tu l'as fournie, archive les fichiers fichiers-à-save du répertoire courant. Est-ce que tu as pensé à faire préalablement un cd pour te placer dans le bon répertoire ? (peut-être que lorsque tu exécutes le script manuellement, tu t'étais bien placé dans le bon répertoire pour voir le résultat…)
Tu expliques aussi que ton fichier de log est vide mais que contient-il si tu rediriges aussi la sortie standard et pas seulement la sortie d'erreur ?

Salut,

Tu peux essayer ça : http://www.workrave.org/

En plus, tu pourras même le faire installer par tes collègues sous Windows et te synchroniser sur le réseau local pour que vos pauses tombent en même temps.

Salut tout seul,

Est-ce qu'il y a une ligne dans ton script indiquant l’interpréteur à utiliser (première ligne, commençant par #!) ? Sinon quel est le shell courant ?

Peux-tu vérifier qu'il n'y a pas quelque part un caractère invisible qui viendrait polluer le code, comme une espace insécable ou quelque chose dans ce genre-là ?

Lorsque tu lances ta commandes, comme le nom de ton répertoire contient des espaces, rm essaie d'effacer Hankow ET 1903-1910. Il n'existe pas de fichiers ou de répertoires avec ces noms donc rien n'est effacé. Comme tu as spécifié l'option -f, il n'y a pas non plus de message d'erreur (voir la documentation de rm).

Pour que cela fonctionne, il suffit que tu mettes des quottes (simples ou double) pour encadrer le nom du répertoire de façon à ce que les deux mots soient considérés comme un seul paramètre.

Toujours pas bon…
Pour le retour à la position classique (horizontal), il faut un "--rotate normal" (right fait une inversion complète par rapport à left).

Salut,
Ce comportement est causé par sed qui bufferise la sortie.
Tu dois pouvoir obtenir le comportement qui t'intéresse en ajoutant l'option "--unbuffered" à sed.