cg a écrit 1745 commentaires

C'est juste le temps de tester, mais en effet il faut avoir 2 écrans. Tu peux faire un autre test pour savoir si tu es sur un display physique : si tu as 2 souris, tu en branches une sur le remote, et quand tu bouge la souris du remote, ça bouge le pointeur dans VNC.

Ceci dit, je suis persuadé qu'on doit pouvoir autoriser la gestion des ressources locale d'une machine avec les bonnes règles dans polkit ou des sessions X.

Ah oui, en effet ça ne règle pas le problème, car tu arrives encore sur un display virtuel.

Ce dont je parle c'est plutôt x0vncserver ou x11vnc (dispo aussi dans Debian).

Si tu arrives sur le display "physique", en branchant un écran sur la seconde machine tu vas voir tout ce que tu fais en remote sur cet écran. C'est un mode d'accès quand même différent, surtout en terme de confidentialité, à voir si ça te convient.

Cela fonctionne quand je lance ma session en physique (via lightDM), mais non pas quand j’ai ouvert ma session X via VNC.

Si je comprend bien, tu ouvres ta session genre VNC sur SSH ? Si c'est le cas, tu ouvres un genre de bureau virtuel, qui n'est pas attaché aux entrées/sorties locales de ta machine distante.

Pour que ça fonctionne comme tu le souhaites, une possibilité est que le serveur VNC se branche au display local, sur lightdm qui gère le display "physique" de ta machine distante.

Ton client VNC se connecte sur ce serveur VNC.

[local: client VNC] --> [remote: serveur VNC] --> [remote: lightdm]

Il existe peut-être d'autres possibilités en jouant avec polkit ou les seats, mais je ne connais pas non plus.

Peut-être que des paquets comme thinlinc (vnc) ou x2go (nx) peuvent t'aider à obtenir la config que tu souhaites plus simplement.

Pour ceux qui aiment, le livre Core Memory propose des chouettes photos et un petit texte sur une bonne sélection des ordinateurs de cette époque, et quelques uns plus modernes.

Est-ce que les stats de distributions comme debian ne possèdent pas un début de réponse sur l'usage de reiserfs (et reiser4) ?

Oui, il y a :

En baisse notable : https://qa.debian.org/popcon.php?package=reiserfsprogs
En augmentation notable : https://qa.debian.org/popcon.php?package=xfsprogs
En augmentation stellaire : https://qa.debian.org/popcon.php?package=btrfs-progs

Et puis franchement quand y'a une corruption de ReiserFS c'est pas la joie :D

🤖 GitLab Bot 🤖 @gitlab-bot added popular proposal label 7 hours ago

En effet, pour Github ça fonctionne, merci !

Par contre il faut être logé pour ça : la préférence ne reste pas après le logout.

Je n'avais jamais essayé sur mon ordi pour le login, mais avec une Yubikey "Security Key" (la bleue pas chère), ça fonctionne. J'ai suivi les instructions du wiki de Archlinux (coup de bol je suis sur Arch ;) ) :

Tout d'abord, vérifier qu'on a un backup sous la main, ou un système de secours genre live-usb.
Ensuite, s'ouvrir un shell root dans une console, au cas où.

Installer le package pam-u2f.

Se créer une empreinte de la clé (ici, mil c'est le nom de mon ordi) :

pamu2fcfg -o pam://mil -i pam://mil > ~/.config/Yubico/u2f_keys

Premier test, en activant le MFA seulement pour ssh :

charles@mil  ~$ cat /etc/pam.d/sshd
#%PAM-1.0
#auth     required  pam_securetty.so     #disable remote root
auth      required  pam_u2f.so  origin=pam://mil appid=pam://mil
auth      include   system-remote-login
account   include   system-remote-login
password  include   system-remote-login
session   include   system-remote-login

Essayer une connexion ssh sur localhost, youpi ça fonctionne !

Second test, globalement :

charles@mil  ~$ cat /etc/pam.d/system-login
#%PAM-1.0

auth       required   pam_u2f.so nouserok cue origin=pam://mil appid=pam://mil
auth       required   pam_shells.so
auth       requisite  pam_nologin.so
auth       include    system-auth
[...]

Ici, il y a des options :
* nouserok pour laisser entrer les users qui n'ont pas de clé u2f configurée
* cue pour afficher le message "please touch the device".

Sur ce second test, ça a activé le MFA sur le login console, lightdm, ssh, mais pas sudo : ce dernier utilise system-auth et pas system-login.

Dans le cas d'un homedir chiffré par la clé, il faut bien sûr mettre les clés en dehors du homedir, bien sûr.

Voilà pour un premier test concluant ;), bon dimanche !

Ce qui me les brise, sur gitlab et github, ce sont les pages qui interceptent le / qui sert normalement à chercher dans la page, et privilégie le moteur de recherche interne du site. Je peux certes faire ctrl-f, et sans doute que ça peut se désactiver avec du userscript, mais je n'y connais rien en la matière.

En attendant ça m'énerve :).

… c'est qu'on a pas de repères d'échelle. En fait ce sont des thermomètres pour diplodocus. Les piles font 1m³ et pèsent 1,8 tonnes chacune.

Les commandes sar (dans sysstat) et atop font la collecte de plein de métriques.

atop et sar peuvent tourner en démon et permettent de rejouer les fichiers. sadf permet de convertir les données collectées par sar en graphes, entre autres.

En lisant et relisant le texte en Anglais, je ne parviens pas à changer ma compréhension :

We’ve been contemplating a different config syntax which reverses the ordering of user and command. Instead of a user focused approach, specify the command first, then the set of permitted users. It should be equivalent in expression, but perhaps the reversed order would encourage users to think about minimal permission grants

puis :

Coming full circle, […] I have built the thing I hate

Pour résumer, j'avais une super idée, elle ne marchait pas/n'était pas pratique, et au final j'ai reproduit le schéma dont je souhaitais sortir.

Une vraie catharsis ;).

L'expression est reprise plusieurs fois :

permettant d'ajouter des fonctionnalités aux CPU

Or, il s'agit de déverrouiller des fonctionnalités déjà présentes ! Point de FPGA permettant effectivement d'ajouter des possibilités dans le CPU.

Pareil, j'utilise us-intl au boulot et altgr-weur à la maison, c'est plus pratique que l'Azerty je trouve.

plutôt que donner des droits à l'utilisateur, on indique la commande puis les utilisateurs autorisés. Ça devrait contraindre l'administrateur à être plus attentif.

Mmmm, c'était le plan, mais la syntaxe n'a pas suivi semble-t-il. D'après le man de doas.conf, on indique bien l'utilisateur en premier.

tedu peut exécuter en root la commande /usr/sbin/procmap :

permit nopass tedu as root cmd /usr/sbin/procmap

Manifestement, tu n'as pas lu l'article lié ;). On y lit que Proxmox = caca et Ceph = fesses avec du caca.

Je pense que le filesystem non distribué qui se gère à la fois au niveau fichier, tout en faisant attention qu'on ne vient pas lui chatouiller les blocs par derrière n'existe pas.

En distribué, il y a Gluster, Ceph, mais tu n'en veux pas, soit (de toutes façons ton infra est trop petite pour que ça fonctionne bien, pas de regrets !).

NFS n'offre pas une copie locale, tout passe par le réseau, même si on peut avoir un cache local pour les lectures avec FS-Cache.

Mais Syncthing pourrait convenir. Sur une partition NON répliquée par DRDB, Syncthing va synchroniser les données au niveau fichier de manière bidirectionnelle et asynchrone. Tu peux choisir un délai de synchro (1 seconde, ou quelques minutes, ou seulement en cas de reconnexion au réseau). Ainsi, tu as ton filesystem tout simple, et une synchro des données avec gestion des conflits.

Vu tes contraintes, ça me semble pas trop loin de ce que tu peux espérer.

Facebook menace de retransmettre un concert du groupe Europe dans le metaverse.
L'ultimatum étant posé, le compte à rebours a commencé.

Pas mieux.

Peut-être que c'est possible avec une partition ext4 en lecture seule, ceci dit.

tu cherches un système de fichier qui permette de monter une partition sur plusieurs VMs depuis un même hyperviseur, tout en garantissant son intégrité ?

J'aimerais aussi qu'on force les fabricants de terminaux mobiles à mettre en place un dispositif de coupure physique des micros de ces espions

Edward Snowden avait posté une vidéo dans laquelle il montre comment supprimer les micros et caméras intégrés d'un smartphone. Ainsi, le téléphone ne peut plus écouter en permanence. Il faut alors brancher un micro externe (genre les fameux petits écouteurs/micro en Y) pour pouvoir parler dans le téléphone.

Bon, faut un peu de matériel et avoir de bons yeux ;)

J'en avais utilisé dans un projet artistique (pour faire tomber des citations littéraires du plafond d'une médiathèque, avec la fonction "coupe de papier automatique" intégrée à l'imprimante). De mémoire, sous Linux c'était quand même pas gagné, c'est souvent des drivers un peu moisis et proprio, avec une doc minimaliste.

J'en ai aussi vu dans des expos d'art contemporain de temps en temps, en écriture automatique par exemple.

Je savais bien que le cartel de la grosse saucisse AAAAA n'était pas loin :).

Il y aussi l'expression Big Tech, plus liée à Big Tobacco, Big Oil, Big Pharma, (mais pas Big Oudaine)…

L'extrait ne dit pas si ces collaborations avec les chercheurs concernent du code ou des projets libres (ou même open source). L'abstract du papier d'origine ne le dit pas non plus.

Mais oui, c'est un (autre) problème.

Il y a confusion entre trois concepts :

• le chiffrement des données pendant la transmission (dans le tuyau, sur le réseau) (par exemple, HTTPS ou STARTSSL).
• le chiffrement des données au repos (sur un disque dur par exemple), ce chiffrement étant assurée par celui qui stocke (le serveur). (par exemple, Luks ou TrueCrypt).
• le chiffrement de type zero knowledge, dans lequel c'est le client qui chiffre ses données avant de les envoyer au serveur, sans jamais envoyer la clé de déchiffrement. Le serveur stocke alors une "truc" dont il ne sait rien. (par exemple, Keepass ou Bitwarden, ou encore Framadrop ou Lufi).

Je pense que ce que tu appelles double-chiffrer, c'est le chiffrement des données par le client, avant l'envoi au serveur.