bubar🦥 a écrit 6904 commentaires

je ne sais pas d'où tu as récupéré cette croyance…

Sous w2k il était courant de casser ses clefs en les retirant à chaud, le système tripatouillait dedans sans rien dire (pas seulement cache et pas de sync) C'est d'ailleurs un des premiers trucs qui m'a épaté sous Linux, à l'époque le système ne touchait jamais si tu n'avais rien demandé.

Up pour une balise vidéo, mais uniquement pour PeerTube.

Du 17' en fullhd à moins de 600€ sous linux, pas facile.
Le BN37721 (base G3 17-3779) de chez DELL semble convenir :

• 8th Generation Intel® Core™ i5 8300H
• Écran FHD (1 920 x 1 080) antireflet de 17,3' (IPS & led)
• 1 x 8 Go de DDR4
• 1 DD hybride (avec 8G de cache)
• Wifi / BT Intel (donc pas un modèle "killermachin©")

Le tout livré avec Linux.
650€HT

https://www.dell.com/fr-fr/work/shop/cty/pdp/spd/g-series-17-3779-laptop/bn37721

ps : le descriptif ne mentionne pas si le dd est remplaçable, le contraire serait étonnant, ni s'il y a un port ddr ou deux, ni si la carte à un port m2. Et une cg Nvidia 1050, et une RJ45, et aussi un port type -c tb3 sur la CM mais le capot livré n'a pas la prise ;-)

c'est exactement ça qui est rigolo : à la fois la pertinence du constat sur les droits demandés en vrai par les packs dispo, contradictoire avec le discours sur flatpack, et à la fois le fait que l'argumentaire est au final assez faible puisqu'il ne peut reprocher au final que ça. Une belle poilade, en somme.

on peux aussi faire comme ça :

• Installation des paquets nécessaires sur kimsufi_new.
• Configuration nginx, base de donnée, memcache …
• Arrêt nginx sur le serveur kimsufi_old
• copie du /…/nexcloud de kimsufi_old vers kimsufi_new
• Dump de la base de donnée de kimsufi_old vers kimsufi_new et de tout le data
• Installation de nextcloud sur kimsuffi_new
• Récupération des .htaccess et du config.php essentiel de _old sur _new
• démarrage nginx sur kimsufi_new
• Paramétrage nextcloud et ses apps
• Normalement ça tombe en marche
• Transfert DNS : nexcloud --> kimsufi_old ==> nextcloud --> kimsufi_new
• Arrêt de _old.
• Synchro finale de bases

Ainsi tu évites un long arrêt de service
(et si tu as plein d'utilisateurs qui synchronisent plein de data depuis plein d'endroits [chez eux, leurs téléphones, etc ..] comme moi, tu remplaces la simple copie par un rsync)
(et tu repars avec un nextcloud neuf, en ayant juste gardé l'essentiel.)

Dans la vie réelle il y a toujours ./configure --help ET la lecture du script, car c'est très courant que le configure ne te donne que QQ options, voir parfois aucune à part les siennes, donc IRL on lit
Non ?

Si ça peut aider des gens utilisant Fedora, le Zero-K_linux64.sh :

#!/bin/sh
ln -fs /usr/lib64/libc.so.6 linux64/libc.so
export TERM=xterm
export LD_LIBRARY_PATH="./linux64:$LD_LIBRARY_PATH"
optirun ./Zero-K_linux64 "$@"

(notes : optirun si vous utilisez une carte graphique discrète)

La ³bune ?
totoz.eu ?

ce qui t'as posé pb n'est pas firejail mais la politique pour firefox de firejail.

Je me suis mal exprimé dans le précédent commentaire, donc précision nécessaire : la gestion des ecrans, ainsi qu'une multitude autres trucs, sont bien mieux faites par défaut dans GNOME (c'est une évidence tellement évidente aujourdhui que je ne l'avais pas mentionné)

Mais qu'il existe aussi des cas où c'est problématique.

Ce que je voulais dire c'est que ces PB là même s'ils existent même s'ils enquiquinants, ils ne sont pas graves : une conf pour fixer et ça fonctionne. C'est donc incomparable avec un PB général de perfs.

Si ce n'est que cela, ça va : un fichier de conf et c'est tout.

Perso c'est dans une config "discrete" où l'on utilise l' "offload" en plus de "prime" (plutôt que de rester en "discrete") afin d'avoir un plein support Vulkan (bumblebee ne sachant faire) : Gnome était tout perdu, il inversait les écrans, ne trouvait jamais la bonne résolution pour l'edp du laptop (cad : il ne la proposait même pas, pas seulement 'il mettait la mauvaise'). Un fichier de conf et hop, résolu. Rien de grave.

Bonjour,

Que pensez-vous de cette fonctionnalité sur un Samsung Galaxy S7 ?

Impossible de s'avancer à dire quelque chose / faire une réponse à votre question, sans avoir pu tester au préalable. Il semble que certains constructeurs soient connus pour fucker (dégrader :p) l'implémentation du profil professionnel d'AOSP sur leurs téléphones destinés au grand public.

Samsung a son propre système (Knox), qui a été "fusionné" avec le système du profil professionnel d'AOSP depuis qq versions. Ce qui est encore un autre cas. Si un Samsung a été flashé (avec LineageOS par exemple) l'appareil va activer un système qui empêche d'utiliser Knox. C'est encore un autre cas.

Pour un S7, vu son tarif, je ne m'aventurerai pas (personnellement) à essayer d'activer le profil pro d'AOSP (via shelter ou à la main) sur le système d'exploitation livré.

Quel smartphone utilisez-vous avec Shelter ?

Un Sony de milieu de gamme.
(sur un XA1 soc mediatek, avec mon système, et sur un XA2 soc qualcomm tout neuf avec LineageOS.) Sur le XA2 il n'est pas possible d'isoler les empreintes digitales (entre profil base et profil pro), pas grave : code pin et voilà ça fait le job.

il ne donne aucune liste de compatibilité.. Je n'en ai d'ailleurs trouvé aucune

Pour s'aventurer à publier cela il faudrait pouvoir tester sur un grand nombre de téléphones (et de systèmes), ce qui est compliqué.

s'il est possible de faire de telle "optimisation" c'est qu'à la base toute cette "suite" logicielle est codée par dessus la jambe

C'est faux, à la base c'est du développement de chez Intel (OpenedHand pour Clutter, racheté par Intel pour le développement de Moblin) et c'était remarquablement bien fait : gestion dynamique des bureaux virtuels, animations sobres, super rapides et bien agréables du gestionnaire de fenêtres. C'est ensuite que tout s'est gâté (du point de vue : rendu visuel et performances ressenties) avec de bonnes raisons : lorsqu'il a fallu intégrer ça à Gnome d'une part, puis aussi se soucier d'autres environnement matériel (qu'une cg intel) et architecture (que x86), puis assurer la transition en douceur vers Wayland.

Ah tiens, merci pour ces liens, je n'avais pas lu cet article sur phoronix. Ok pour Clutter, cela sera t il suffisant ? Qui vivra verra.

J'espère car avec Gnome ma machine perds 8fps sur tomb-raider, par rapport à kde, 8fps, soit 20% de perfs en moins (sic) juste parce que j'utilise Gnome. Le chemin va être encore très long pour ce bureau.

-next a intégré et intègre toujours pas mal de choses venant, entre autre, de GRsecurity. On peut remonter pour voir les causes publiques du dernier clash avec grsecurity, pour ce côté là du moins, mais ce message récent, sur une demande récurrente et qui ne concerne nullement grsec, semble bien plus sympa à lire.

C'est dans cette branche que ces choses se passent, pour ça aussi, autant techniquement que diplomatiquement semble t il, entre différentes entités. On peut aussi lire des messages d'encouragement et de remerciements de Linus, parfois, ce qui rappelle que Mr Torvalds n'est pas le grand méchant râleur, et que quelques saillies même dures et mémorables, ne devraient pas masquer l'ensemble de son taf.

C'est aussi ce que préconise Gentoo hardened : suivre la branche principale et cela ne les empêche nullement de produire un système pré-configuré. Juste sans grsec :p ce qui n'est pas si grave, non ?

Perso je vais suivre avec intérêt l'usage de partitions A/B, le retour du "toram", le mécanisme de mise à jour, le stateless (configuré différemment entre clearlinux et chromeos par exemple) et l'usage de plus en plus important des capabilities.

À chaque dépêche sur Gnome, j'ai envie d'essayer. Et souvent je le fais (lors de la sortie de la nouvelle Fedora.) Des éléments tels que "jeu" (que je découvre ici) me font bien envie. Et aussi les si nombreuses bonnes idées de ce desktop (le choix des interactions primaires / faciles dans le gestionnaire de fichiers, le choix dans la gestion des bureaux, l'intégration poussée permettant au gestionnaire de logiciels de fonctionner bien avec tout types de paquets depuis les classiques jusqu'au .cab en passant par les flatpacks), la prise de bonnes idées ailleurs (dcop par exemple, aujourd'hui l'équivalent de kde-connect qui est plus joli chez gnome, en restant loin de tout troll…) La liste est trop longue pour citer tout ce qui fait envie dans ce bureau.

Et pourtant à chaque fois je reviens sur ce "truc bricolé dans plein d'endroits différents". Non par habitudes, j'aime toujours la nouveauté et les découvertes, non plus par l'absence chez Gnome de tout ces petits plus qu'apporte kwin, je peux m'en passer, mais bien simplement parcequ'à chaque fois le ressenti est mauvais : un ressenti de lenteur, de lourdeur. Les animations sont lentes, le lancement des outils est lent (le lancement "d'image" met presque 3s avant affichage sur mon i7, pour ne même pas proposer des choses basiques comme rogner ou redimensionner, quand gwenview s'affiche en moins d'une seconde sur le même pc pour la même image)

Et pour se rapprocher des trolls : l'horloge de Gnome ! Ah, l'horloge de Gnome : affiche les secondes, charge ton pc (compilation, game, peu importe) et admire le résultat : l'horloge saute 4 secondes sur 5. Incapable d'afficher l'heure correctement, une machine ? Hum … C'est ça le meilleur bureau linux ? Un truc pas fichu d'afficher correctement l'heure ? Excusez moi, mais je retourne sur ce "truc mal bricolé" (parait il) qu'est KDE, parce que c'est du Qt et que jamais, au grand jamais, il n'y a de pb d'affichage d'horloge. Le problème du bureau gnome, finalement, ce ne serait pas GTK ?

Pareil.
La recherche est un calvaire (le 'seo' n'est visiblement pas leur priorité, ce qui a aussi des bons côtés : plutôt que de chercher sur un moteur un truc à propos de la distro, le réflexe sera de se connecter au site ?!?)

Et, sur un tout autre registre l'absence de Firefox Klar est regrettable.

Sur mes 12 donations régulières aucun des bénéficiaires n'a pour le moment configuré un compte "stripe" (et ce dernier reçoit des commentaires comme étant "invasif dans les questions posées et informations demandées") Il faut donc attendre un peu que les bénéficiaires, personnes et/ou projet, fassent le nécessaire de leurs côtés.

Le retour de Liberapay est une excellente nouvelle \o/

c'est ce qui m'intéresse le plus en tant qu'utilisateur : une gestion plus fine des "droits" (entre guillemets et en italique pour insister sur le côté "vue utilisateur" et non pas sur les droits unix). Par exemples :

• que mon navigateur internet n'ai pas accès à mon dossier Documents, mais juste Public et Téléchargements ;
• que que mon logiciel de visionnage de photos puisse écrire de nouveaux fichiers dans .thumbnails mais pas lire les fichiers qui y sont déjà ;
• que chacun de mes logiciels puisse écrire dans .config .local .autre mais juste dans leurs dossiers respectifs, sans pouvoir ni lire ni écrire dans ceux des autres

C'est une partie du point de vue d'Android il me semble …
Et une partie de la réponse ne se situe pas dans les droits UGO mais dans ceux-ci + une grosse gestion d'uid et de guid côté système + le concept de déclaration de racine et d'isolation (dont l'implémentation pour arriver au résultat peut être diverse : chroot, sandbox selinux, usage des namespaces, utilisation de points de montage bind à la demande, ..)

Il y a pas mal d'arguments contre ça, d'un point de vue système et kiss, mais il y a aussi pas mal d'arguments pour, et à l'heure où le soucis central c'est l'accès à nos données par des tiers sur le réseau via des apps que j'installe, il est peut être tant de se dire qu'en 2018 il est complètement con que les navigateurs aient accès par défaut aux clefs privées dans .ssh.

Des différents points abordés par plusieurs commentaires, il m'apparait un élément, peut être je me trompe mais je le soumet à la sagacité des autres lecteurs et à la votre :

Il semble qu'il y a une incompréhension dû à l'objectif expliqué :
D'une part cela cause d'un objectif vague, une "réduction de la surface des droits accordés" ;
D'autre part cela cause d'implémentation, et d'autres systèmes ;
Et enfin on revient sur votre postulat de base et votre descriptif d'introduction.

La situation est déjà assez complexe : droits unix de base souvent mal utilisés (il est pourtant simple, par exemple, de ne pas donner un droit de lecture tout en accordant un droit d'écriture, mais ce n'est pas très pratique :p en l'état), attributs étendus (utilisés aussi bien, par exemple, pour le system acl que pour la security selinux), auxquels s'ajoutent parfois les capabilities (pour éviter, par exemple, un bit_suid sur la commande ping). D'ailleurs j'ai une question simple : lors de la création d'un nouveau groupe, comment définit on les capablities qu'on accorde à ce groupe ? :p

Donc si j'ai bien compris votre postulat de base peut être résumé en : «on ne touche presque rien au système existant» (sinon, et si votre objectif avait été la "réduction de la surface des droits accordés", vous auriez peut être procéder autrement en utilisant massivement des combinaisons fines et nombreuses entre des utilisateurs et des groupes pour les logiciels et des acl en plus pour les arborescences, cette solution suffit mais elle nécessite de modifier les post-install des paquets, au final d'entretenir une distrib, presque, mais reste moins couteuse que de modifier les logiciels eux-mêmes tel que le pratique OpenBSD pour aller plus loin). Vous partez du constat de l'existant en matière de distribution, presque tout est root:root pour les logiciels, seuls trois ou quatres binaires ont des cap déclarées, et les programmes plus ou moins bien fait demandent eux mêmes et/ou font de l'abandon de privilèges.
Ce postulat de base est important, primordial, et je ne doute pas qu'il puisse être exprimé autrement, mieux, plus finement, pour dire quelque chose comme "on travaille sur la distrib telle qu'on l'a, et on ne la refait pas".

Ensuite votre introduction peut être résumée en "remplacer sudo par quelque chose qui prenne en charge les possibilités offertes par le système des capabilities", finalement. Et cet angle d'attaque est, je trouve, imho tout ça, particulièrement intéressant, et pertinent.

Vue ainsi cela ressemble à la continuation logique de l'élimination des bit_suid en utilisant les capabilities. Vous le proposez de manière dynamique, sans toucher à la distrib, et facilement configurable.

Critiques générales :
Si le modèle du super-utilisateur est si utilisé c'est parcequ'il correspond au besoin de la plupart des usages, qui restent finalement assez simples. Que cela soit sur un serveur web, un serveur de vm ou un ordinateur personnel, ce modèle simple et loin des possibilités du système suffit pourtant. La crainte est donc que, même avec une certaine simplicité de configuration, cela ne soit pas ou peu utilisé sans proposer des politiques par défaut déjà prêtes (ce que fait, pour un autre objectif et un autre type d'implémentation, firejail, ou encore différent : suricata). Quant à demander d'utiliser une commande préalable à tout autre, cela restreint bien probablement l'usage de sr à quelques environnements multi-utlisateurs / multi-administrateurs où le cloisonnement de responsabilités est primordial. Mais également très intéressant pour un ordinateur personnel, dès lors que des règles sont livrées établies et maintenus (comme le disait Linus : c'est stupide d'être root pour configurer une horloge, une carte graphique ou une imprimante sur son PC personnel) : pour ce cas aussi il y a une voie ..

Ces deux critiques posés, il semble nécessaire de répéter que je trouve votre approche de remplacer sudo par un utilitaire de gestion des capablities particulièrement pertinent. Alors une question : qu'est ce qui a fait que vous ayez choisi de développer un module à part plutôt que de contribuer à sudo ? (il n'y a ni malice dans la question, ni bonne ou mauvaise réponse, juste une demande d'info)

Enfin, deux remarques sur le configure et le déclaratif pam : dans le configure il y a un mélange entre dépendances nécessaires à la compilation et post-installation, envisagez vous de séparer les deux ? Par exemple avec un simple readme pour dire ce dont il a besoin, et ensuite une bascule des cp et chmod dans le Makefile ? Ensuite concernant la règle pam : elle n'est pas distro agnotisque, mais elle est très simple donc envisagez vous de la rendre plus générique ? Ces points font qu'en l'état actuel il n'est pas possible d'utiliser immédiatement votre module sur autre chose qu'une Debian. Enfin, vu qu'il a un besoin strict de pam, il ne sera pas possible de l'utiliser sur une Slackware par exemple. Du coup, il serait peut être bien d'ajouter une note à ce sujet car sr n'est pas "pour linux", mais pour une distrib basée sur Debian (pour le moment du moins) et qui a pam.

Oui, et si c'est un contexte changé par rapport à ce que le gestionnaire de paquets attends (qu'il lit du spec du paquet), par exemple parcequ'on utilise un endroit non-standard (cas courant avec apache) alors la création d'un module spécifique de règles selinux correspond au besoin : ne plus avoir en s'en occuper. semanage et zou, simple efficace.

On peut scripter aussi, pour mettre des attributs plus cools automatiquement sur l'espace data de nextcloud, par exemple, pour profiter de la mise à jour en "full web", puis remettre tout ça plus correctement après, en automatique.

Et pour démarrer, rien de vaut le retour de logs de setroubles en preprod, il dit quoi faire et comment faire dans 95% des cas, y a plus qu'à pousser en prod. Bref, SElinux c'est pas si compliqué que ça (tant qu'on ne touche pas au :sX ..)

C'est un peu hors-sujet avec la dépêche, cette tirade. Par contre je me demande comment selinux et rar cohabitent. Hop, direction les tests.

J'ai oublié l'évident : c'est une élégante solution ta propostion.

Test ce week end !
Merci

wow un zuk \o/

Deux remarques qui (je l'espère) pourront compléter ton propos :

pour pouvoir installer TWRP

Ce n'est pas absolument nécessaire pour la majorité des téléphones : un simple fastboot boot twrp.img est suffisant pour accéder à twrp et flasher lineageos. En plus, ensuite on a le recovery lineage, qui fait moins de trucs.

enregistrer ses données par ailleurs, et de se préparer à faire une réinstallation à partir de zéro

Dans la plupart des cas c'est le mieux, et de toutes façons ce qui nous importe ce sont nos données, et pas les apk installées. Pour nos données adb fait le job (sauf pour les apk type bancaire et qq jeux, où il faudrait être root, mais c'est pas grave.) Donc décomposer cette phase en deux parties différentes : la sauvegarde / restauration de nos données et préférences d'un côté, et d'un autre côté la ré-installation des apk. Pour la seconde partie perso j'ai choisi un deuxième appareil, qui reste chez moi, et qui a accès au play-store : ainsi j'ai les mises à jour en dehors de l'appareil qui me suis partout tout les jours ;-) Sinon je ne connais pas yalp mais j'ai bien aimé aurora et son système d'information sur les mouchards présents dans les apk sur play-store : ça aide à faire le tri.

Salut,

des tutos en français clairs et simples

Le problème des tutos, c'est qu'il y en a tellement qu'on s'y perds. Et puis en faire de qualité est difficile. Enfin, si on en fait un, de temps à autre, de qualité alors il faut le proposer au projet concerné lui-même.

Bien que ce bordel soit fatiguant lorsqu'on cherche une information, il est indispensable. Pour le cas des tutos, cela permet de partager modestement une trouvaille, ou encore simplement de ré-écrire pour répondre à quelqu'un. Enfin, cela permet de se faire la main et petit à petit améliorer son écriture (élaguer tout ce qui sert à rien dans ce qu'on écrit par exemple) et peut être un jour être plus utile à toutes et tous, via un projet ?

Mais c'est énervant quand on cherche. Alors la bonne réponse c'est rtfm :-) Dans le meilleur sens du terme : simplement lire la doc officielle du projet. Et si cela parait pas assez clair ou incomplet, alors poser la question sur cette doc, voir proposer un changement dans cette doc.

pour un ZTE FF_os

Cet appareil ne semble plus maintenu par personne, même son ancienne page officielle https://developer.mozilla.org/en-US/Firefox_OS/Phone_guide/ZTE_OPEN_C est un 404. KaiOS ne semble pas avoir de port pour ce modèle.
Cependant il y a cette page, d'un mainteneur indé, et dont le tuto est excellent en plus https://konstakang.com/devices/kis3/CM14.1/ c'est pour LineageOS 14, pas mal du tout, chapeau bas, monsieur.