Reprise du message précédent :
arrivée dans le dépôt stable du noyau 3.18.x, un mois jour pour jour après sa sortie officielle, c'est peut-être le record en terme de retard dans l'histoire d'archlinux concernant le noyau linux

j'ai tenté de construire le paquet linux en utilisant le PKGBUILD d'origine :

https://projects.archlinux.org/svnt [...] ages/linux

ça me donne une erreur :

vous avez la même chose ?

c'est chaud de comprendre ces explications :

https://bbs.archlinux.org/viewtopic.php?pid=1493650
http://allanmcrae.com/2015/01/two- [...] rch-linux/

la solution viendra peut-être d'une modification du wiki archlinux avec des explications qu'un utilisateur lambda non spécialiste de gpg pourra comprendre

Perso, j'ai utilisé l'option skippgpcheck
   
 
 
 

La page d'Allan me parait assez clair.
En gros tu as 2 "repertoires" de clefs, un pour pacman et un pour makepkg.
Le fait d'avoir une clef dans l'un, ne la met pas dans l'autre.

Idem
C'est une histoire de keychain system-wide pour pacman et spécifique à l'utilisateur pour makepkg il me semble.

KDE 14.12 est dans testing, donc maintenant je suis sour KF5 mais je n'y vois encore aucune difference

Pour voir un changement faut passer à plasma5.
J'ai testé dans une VM, ça semble pas mal, le thème breeze par défaut est plutôt joli, j'ai pas testé en détails cependant. J'utilise pas les widgets, espaces de travail, activités etc...

Ah en effet, je croyais que ca l'avais aussi mis mais en fait non.
Par contre plasma-next m'enleve trop de trucs, donc je vais peut etre attendre un peu.
(En fait je pense pouvoir me passer de tout sauf de mon applet redshift).

 
ça j'avais compris, ce que je cherchais c'est la manipulation dans le fichier de configuration de gpg pour résoudre le problème automatiquement,
 
donc voici la solution :
 

 
en clair: il faut décommenter la ligne "keyserver-options auto-key-retrieve" dans le fichier ~/.gnupg/gpg.conf

Perso j'ai ajouté cette ligne à ce fichier mais c'est peut-être pas suffisant :  

Logiquement, tu ne devrais lancer pacman que via un sudo.

je n'utilise pas sudo ( qui de toutes façons n'est pas installé ), je passe par un script  
 

Pourquoi ne pas utiliser sudo ?

parce que je me débrouille très bien sans
 
sudo est surtout utile quand plusieurs personnes utilisent le PC et que l'administrateur veut déleguer certains droits d'administration à des simples utilisateur,
 
je pense que quand l'administrateur et l'utilisateur sont la même personne ( pas d'autres utilisateurs sur le PC ) alors le plus simple est de se faire des scripts et/ou d'utiliser "su" tout en n'oubliant pas de quitter "su" une fois la tâche d'administration terminée,
 
à noter que dans KDE l'utilitaire kdesu fait le même office que "su" en ce qui concerne les programmes à interface graphique

J'utilise sudo juste pour la simplicité de construction de la commande, j'avoue
En fait je pourrais faire une fonction style
function sudo_root {
 su -c "$*"
}
que ça marcherait pareil pour moi
 
En attendant personnellement sur tous mes pc, j'utilise sudo avec l'option "rootpw" car je supporte pas l'idée que ce soit le mdp de l'utilisateur qui invoque sudo qui soit requis

oui ça me gène aussi le fait qu'en tapant le mot de passe utilisateur ça permet d'utiliser ensuite des commandes administrateur,
 
ça ouvre la porte à des problèmes potentiels si l'utilisateur a un mot de passe facile à deviner, un utilisateur malveillant qui a pris le contrôle de la machine ( faille de sécurité, mot de passe trop facile à deviner, le fiston qui veut faire une blague sur le PC de son père ) va probablement essayer la commande sudo sur des commandes d'administration pour faire un max de dégâts
 
l'option "rootpw" ça annule l'interêt du sudo vu qu'à la base sudo c'est destiné à être utilisé par un simple utilisateur, s'il connait le mot de passe root ça craint un peu pour la sécurité

En lisant ce bug, j'ai un peu peur:
https://github.com/ValveSoftware/st [...] ssues/3671
 
Y'a-t'il un moyen propre et simple de confiner des applications a certaines limites?
Le mieux serait de pouvoir définir leurs permissions de lecture et écriture mais ca parait un peu difficle (du style Chromium peut tout lire dans les repertoires de l'utilisateur mais ne peut écrire que dans un seul repertoire, mpv/mplayer ne peut jamais écrire etc).
 
Je vois des gens dirent utiliser steam dans un chroot, mais devoir installer un os en chroot pour une application parait excessif...
Quelles sont les autres options?

Laisser Steam dans son dossier par défaut, ou celui défini dès le début

  Ce bug ! Tu me fais paniquer maintenant, surtout que je trifouille souvent mes SteamLibrary.
 
Si tu veux cloisonner, je vois plusieurs solutions, parmi les plus simples:
-Créer un nouvel utilisateur dédié à steam. Optionnellement tu peux même scripter un petit launcher pour lui autoriser de se lancer dans ta propre session X courante.
-Chroot + overlayfs par dessus /, dans la théorie ça devrait marcher, mais j'ai jamais trop joué avec
 
Je te conseille la première solution, c'est rapide à faire.

Pas de panique, normalement, le bug est réglé : http://www.linux.com/news/software [...] -on-system

Oui, mais comme toujours c'est un bug particulier qui te rappelle que des bugs comme ça y en sûrement des 100aines dans tous les progs que tu utilises quotidiennement.
Et comme on va pas s'amuser à cloisonner chaque application, le mieux reste encore de savoir réagir en cas de catastrophe, aka avoir des backups.

Ma question n'est pas forcement pour Steam.

Oui mais de nouveau je voulais un truc generic.
Je ne vais pas quitter X, me logger sous un autre utilisateur pour lancer mpv ou xbmc.
Le script qui fait cela automatiquement, en restant dans la meme session X, ca par contre ca peut etre pas mal.
Par contre creer un compte par application, ca parait un brin lourd, mais en meme temps, peut etre est-ce la bonne methode?

En lisant le github jusqu'a mon poste, il y avait un pseuso-fix mais qui etait toujours faible/mauvais.

Justement, pourquoi ne le ferait-on pas?
Bien sur certaines applications communiquent entre elles, mais pour les autres?
Apres pour les sauvegardes, pour les trucs important bien sur, mais pour une mediatheque par example, ou des jeux videos, l'interet est maigre. Il suffira de les reinstaller/retelecharger, mais cela etant bien lourd a faire..

Le problème c'est que tu ne seras jamais exhaustif.
Si on veut être extrémiste, même firefox, amarok,skype,etc... pourraient bugger et effacer le contenu de / récursivement (du moins ce qu'il peut)
Tu ne vas pas pour autant TOUT cloisonner
Une solution générique si tu veux aller par là c'est les conteneurs. Mais c'est l'artillerie lourde pour une problématique pas forcément adaptée.

Si tu acceptes de ne pas être exhaustif et donc pas spécialement protégé de toutes les éventualités (en même temps le risque 0 n'existe pas...) je dirais oui.
Pour le script pour partager ta session X, sans enlever toutes les sécurités, en gros faut qu'en root tu copies ton magic cookie X de l'utilisateur authentifié via le DM vers celui qui veut ouvrir une fenetre, et positionner la variable DISPLAY.
Ca marche pour des applis basiques.
Si faut aller plus loin et gérer policykit/consolekit/XDG là par contre je connais pas trop, mais ça doit pouvoir se faire.

Si tu veux un truc générique, je pense que Qubes OS pourrait à peu près répondre à ton besoin, il sait normalement gérer des VM à la volée pour cloisonner les applis. Mais ça doit être assez lourd à l'exécution (XEN)... Le princpe reste très intéressant. Une version avec des conteneurs légers pourrait s'approcher de l'idéal.

Pourquoi pas?

Un truc avec une VM par application ca parrait bien lourd.
Apres pour le moment je pense juste aux limites du FS pas en memoire (ce qui est probablement important aussi, mais plus dans le cas de virus/faille, que dans le cas present qui m'interesse), donc l'utilisateur parrait suffisant, juste difficile a mettre en place en tant qu'utilisateur.

Peut etre qu'une solution intermediare, un peu comme tu l'as ecrit avant, serait d'avoir un compte utilisateur par domaine d'application.
Genre la mediatheque sur un compte, internet sur un autre, un compte pour les applis venant d'AUR, etc... ce qui limite un peu les degats.
(Apres tout, de nouveau hors virus/attaque, quel est mon interet a conserver /etc si je perd /home ... c'est generalement dans /home que j'aurais des fichiers qui me sont importants, alors que /etc est sous root mais pas /home/gee ca parait incoherent).
Le probleme c'est que de nouveau c'est un truc au niveau utilisateur, un truc au niveau du pkgbuild (en option?) pourrait etre plus sympathique je pense.

La mise en place me parait bien lourde si c'est fait manuellement, et comme faut tester que tout marche bien, le cas par cas me semble obligatoire.

Oui, moi aussi je me focalise plus sur la problématique du FS.
Alors justement, sur Qubes, il me semble que tu pourrais faire une appli == une VM, mais c'est pas ça le but premier, c'est plus des niveaux de confiance et tu intègre plusieurs instances par niveau de confiance. J'ai jamais pu tester parce qu'on ne peut pas l'installer dans une VM

Bon déjà, /etc est protégé en écriture, si tu fais pas l'inconscient en root, tu risques déjà moins.
EDIT/ tu peux même le mettre sur une partition et le monter ro.

Sinon, j'avais pas pensé, mais tu as aussi les solutions comme SELinux qui pourraient faire ce que tu veux.

 
On est d'accord, je ne cherche pas du manuel.
 

ca reste pas mal lourd tout de meme.
 

Oui c'est bien que je voulais dire "/etc est protégé en écriture, si tu fais pas l'inconscient en root" alors que /home non, et pourtant j'ai probablement plus de fichiers qui me sont important dans le 2nd...
Tu me diras "/home/gee est protégé en écriture, si tu fais pas l'inconscient en gee" mais bon..

Je ne connais que de nom, mais aucune idee de ce que ca fait, je vais regarder de suite

Alors vite fait, SELinux, ou son concurrent AppArmor pourrait etre en effet ce que je cherchais.
Je regarderai plus en detail demain, il est un peu tard pour partir sur ce genre de trucs

 
une machine virtuelle où tu lanceras là dedans toutes les applications suspectes, avec les PC d'aujourd'hui la puissance est largement suffisante pour faire oublier qu'on tourne dans une machine virtuelle ( reste le problème des applications graphiques, l’accélération 3D sera moins performante ),
 
comme machine virtuelle il y a virtualbox qui est puissant et facile d'utilisation,
 
seul bémol : les développeurs du noyau linux ont une mauvaise opinion de virtualbox car ils pensent que les modules virtualbox sont mal écrits et pourraient faire planter le noyau linux, du coup ils ont mis une ligne de code qui va mettre en "TAINTED" ton noyau linux lorsque tu feras un rapport de bug, ils vont alors ignorer ton rapport de bug dès qu'ils verront le flag "tainted" dans le log de dmesg,
 
http://www.phoronix.com/scan.php?p [...] &px=OTk5Mw
 
l'alternative : utiliser qemu qui se base sur kvm, mais les performances 3D seront moins bonnes par rapport à virtualbox,
 
il y a aussi le concept de "sandbox" utilisé par certains navigateurs internet, faudrait regarder si ce concept existe pour les applications sous linux,
 
http://en.wikipedia.org/wiki/Seccomp
 
mais le plus important :  
 
- boycotter l'application qui te semble pas fiable ( code source non disponible, développeurs pas sérieux )
- faire des sauvegardes hebdomadaires de tes fichiers les plus précieux ( inutile de sauvegarder les applications et les fichiers systèmes ), ça passe par un script qui sauvegardera les dossiers et les fichiers les plus importants ( mails, photos, textes, tout ce qu'il y a d'important dans ton /home ), utilisation de rsync
 
il ne sert à rien de paniquer et de monter des usines à gaz de type machine virtuelle/autorisations par application, vu que ce bug que tu indiques n'est pas très courant,  
 
en général la catastrophe la plus courante que tu vas rencontrer c'est plutôt le disque dur qui tombe en panne, un orage avec un PC non protégé par un onduleur, la meilleure parade consiste alors à avoir des sauvegardes sur des supports externes ( disques dur USB, clé usb, cloud etc... )

Soit la PR a pas été acceptée, soit ça a été enlevée mais si je regarde le fichier concerné aujourd'hui il n'y a plus le taint forcé.

Bonjour,

J'allais poser une question mais je l'ai résolue.
Pour info, j'essayais de monter une partition truecrypt automatiquement au démarrage en suivant le wiki, mais ça ne fonctionnait pas. En fait dans crypttab, il met tcrypt-system, alors que je voulais une partition simple, donc tcrypt. Comme ça parlait de container au-dessus et non de partition système, j'ai mis un moment à trouver.
Si ça peut servir à quelqu'un.

edit : pour la ligne de fstab, ça monte en root, j'ai modifié comme ça (et viré le noauto et ajouté discard (SSD) dans crypttab aussi) :
/dev/mapper/truecrypt1    /media/truecrypt1    ntfs-3g    rw,users,gid=100,uid=1000,nls=utf8,umask=002,x-systemd.automount    0    0

Si tu penses que le wiki n'est pas clair tu peux l'éditer

sinon il peut aussi regarder le wiki des autres distributions concernant truecrypt ( ubuntu, fedora, debian ), souvent les infos sont réutilisables pour archlinux,
 
 

 
en effet je viens de faire le test en chargeant les modules de virtualbox, je n'ai plus la mention "tainted" dans dmesg,
 
par contre quant je fais un "cat /proc/sys/kernel/tainted" j'ai la réponse "4096" qui signifie qu'un module "hors tree" a été chargé

Helas la VM n'est pas une option qui m'interesse, mais pourquoi penses-tu que les performances 3d de qemu sont moins bonnes que celles  de VirtualBox ?

Apres pour dire que ce bug n'est pas courant, il y a eu plus ou moins la meme chose avec BumbleBee il y a 3 ans.
Bon, tu me diras, une fois tous les 3 ans... mais peut etre il y en a eu d'autres entre temps.
Il n'est pas impossible que je fasse la meme boulette moi-meme en ecrivant un de mes pkgbuild, on ne sait jamais donc je regarde ce qui est faisable.
Enfin c'est plus un truc qui m'interesse en theorie, un peu comme sous windows mon utilisateur etait admin, donc il pouvait tout chambouler, en passant a nux, on change cela, peut etre y a-t il une 2nd chose a changer encore.

 
Je ne pense pas avoir le niveau pour être en mesure de dire comment les choses doivent être faites. J'ai cependant ajouté deux lignes qui, pour moi, clarifie le wiki.
 

 
C'est ce que je fais à chaque fois, mais je n'ai rien trouvé d'utile à mon cas précis.
 
 
Une autre question :
Dans ce cas de montage automatique, j'ai dû créer un fichier avec le mot de passe écrit en clair dedans. Quand le pc est éteint, pas de soucis, la partition système est chiffrée, mais quand il est allumé, quelqu'un qui s'y connait un peu pourrait accéder à ce fichier et lire le mot de passe. Il y a une solution pour ça ?
Je ne veux pas utiliser de keyfile au cas où j'ai à ouvrir ce volume sur un autre pc, c'est plus facile de retenir le mdp.

personnellement pour stocker tous les mots de passe j'utilise keepassx :

https://www.archlinux.org/packages/ [...] /keepassx/

donc si tu veux stocker tes mots de passe dans un fichier comme un "pense-bête/post-it" alors le mieux c'est d'utiliser keepassx qui va stocker tes mots de passe dans une base de données protégée par un mot de passe ( on peut même renforcer la sécurité via une clé USB contenant un fichier clé  ), c'est beaucoup mieux que d'écrire le mot de passe dans un fichier texte non protégé,

s'il s'agit d'un mot de passe qui doit être obligatoirement présent en "clair" afin que systemd ( ou tout autre brique système ) puisse l'utiliser alors si tu ne veux pas qu'un simple utilisateur puisse lire le fichier il faut faire un "chmod 600" sur ce fichier texte, ainsi seul le propriétaire du fichier ( à priori le compte root ) pourra lire et modifier ce fichier texte,

regarde aussi le manuel s'il existe un moyen de crypter le mot de passe dans le fichier ( un peu à la manière de ce qui se fait pour le wifi avec netctl ) :

https://wiki.archlinux.org/index.php/Netctl#Wired

j'ai testé virtualbox et qemu, il y a pas photo : pour l’accélération 3D sous virtualbox a pris de l'avance grâce à leur module vboxdrv, l'affichage est plus performant,

sous qemu c'est un peu l'anarchie, il existe plusieurs pilotes vidéos plus ou moins optimisés, le meilleur est "qxl" si on utilise spice mais ça reste en dessous de virtualbox niveau performance graphique, et ce pilote marche mieux avec un guest windows qu'avec un guest archlinux où j'ai remarqué des bugs d'affichage

 
J'utilise aussi keepassx, mais c'est effectivement un fichier pour utilisation par le système. J'ai fait un chmod 600, c'est « intelligent ».
 

 
Je vais regarder ça, merci.

Heu ? A ma connaissance vbox n'a pas d'accélération 3D pour des guests linux. Seulement une acceleration de X.

pourtant quand j'essayé avec mesa3d ( outil de diagnostic glxinfo ) ça me met "direct rendering: Yes"
 
je vois la différence quand l’accélération 3D est activée ou pas dans un guest linux avec virtualbox
 
https://blogs.oracle.com/fatbloke/e [...] ntu_guests
 

 
il faut juste penser à installer les virtualbox guest-additions dans le guest linux ( avec archlinux un paquet existe pour les guest-additions )

Ha oui, je comprends ce qui ne marche pas du coup : La 3D d'un guest linux sur un host windows

ça doit marcher aussi dans ce sens, vu que sous windows openGl est supporté, et encore en passant par directX pour émuler openGl ça doit marcher aussi ( l'inverse de ce que fait Wine en gros )

Bah sur ma VM vbox au boulot, je peux pas cocher accélération 3D, ça me dit que ce n'est supporté que pour les target windows.