bubar🦥 a écrit 6943 commentaires

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.

Partiel, incomplet, et quelques fichiers portent encore la référence du h31xx. impossible de prédire si cela sera suivi, mais ça bouge un peu :-)

ha ?

C'est vrai, d'ailleurs j'ai été un early adopter de Free Mobile, mais après 2 ans avec sur Toulouse, et des bascules permanentes sur Orange alors que j'avais une antenne Free en face de chez moi, incroyable ça, et une couverture pas terrible dans la région et inexistante dans la partie pyrénéenne proche, stop Free Mobile. Stop. La couverture, passe encore c'est chiant mais passe encore, mais la bascule permanente sur Orange était insupportable (donc un débit fortement réduit, et non je ne rentrerai pas dans le débat pour savor qui réduit, je m'en fiche), Free Mobile c'est terminé.
Et les personnes autour de moi pareil.

L'Arcep aurait peut être dû forcer à mettre fin à l'itinérance Orange pour Free, ça aurait peut être été mieux …

Une autre solution est d'avoir un terminal 'android par défaut', d'importance secondaire (qui n'est pas transporté sur soi en permanence, qui n'a pas les sms et contacts et appels téléphonique, tout ça .. un vieux téléphone bien maintenu ou un petite tablette font très bien le job : ça bouge pas de chez soi et ça ne sert qu'à ça : avoir les mises à jour des apk pour les poser sur son appareil personnel)

Merci pour cette info, très bonne nouvelle.

Et devinez quoi, pas mal de logiciels ne savent plus utiliser que ce dernier, et ne fonctionneront donc pas sans Google Play Services.

Certaines boites sont à l'écoute. Par exemple Orange Bank : les premières versions ne fonctionnaient pas sans les services google, qq ralantes amicales plus tard, les dernières mises à jour permettent d'utiliser leur App avec un téléphone où il y a 0% de google services dedans. Il y a toujours le message au lancement de l'app, mais elle fonctionne. Merci Orange Bank :-)

Quant à LCL son app a toujours fonctionné sans les services google.

Bref, les trucs importants sur mon téléphone 0% google fonctionnent sans problèmes.

C'est exactement ce qui m'a poussé à faire ce journal, une des deux raisons : voir la liste des appareils qui ont un support en 15.1 est un peu déprimant, et plus quant on sait que certains support s'arrêtent brusquement. Mais la qualité de la distro est vraiment au rendez-vous.

Difficile, impossible, de dire si ce qui semble être un sacré palier à franchir avant d'avoir son port accepté, est un frein pour les contributeurs où un bénéfice pour la distribution, quelle est la part de chacun, et quel sera l'avenir proche.

Mais je suis de nature optimiste :-)

Pour ma part ça fait près d'un an que je ne peux plus mettre à jour

Quel matériel ?

(sony) Si on pouvait me confirmer cela serait cool.

Ici, Sony depuis longtemps (en fait depuis la fin des 'vrais' nexus, ie : bons téléphones, ouverts, et pas chers, puis d'un asus sur soc intel : bien), car on les trouve en magasins (pas possible pour un oneplus), ils disposent d'un excellent support (chose très rare) pour la plupart des appareils, ils sont incroyablement solides (pour les générations 2015/16/17/ début 18, les nouveaux changent de look et j'ai pas encore testé la solidité par rapport aux "briques" d'avant), Sony a un site de bons niveaux (au pluriel) pour l'opensource.
Il y a des bémols : la fameuse partition "TA", sans elle bye-bye les belles fonctionnalités de l'appareil photo / vidéo (entre autre, mas surtout). Ils sont plus chers que les OnePlus.

dans des prix pour etre humain normal (~200/250 euros)

Le XA2 est un bon choix (actuellement à 290 avec un casque bt Sony de belle facture, offert, chez les fabricants de pain) il est plus lourd que l'ancien XA1 en soc mediatek, mais Sony a mis du Qualcomm dans ses milieux de gamme cette année, donc un bon support Opensource avec, comparé à mediatek :-) Le mainteneur LineageOS pour XA2 a failli arrêter les mises à jour, et il était taggué "plus maintenu" mais il y a eu une nouvelle livraison mardi …

Un avis, il y a probablement d'autres modèles sympas.
Perso j'ai continué avec Sony en faisant mon choix parmis ceux de la liste de LineageOS : XA2 bon support et plus maintenu : parfait :)

Cette refléxion est basée sur le résultat instantané, et par corollaire :

Mais le besoin de reconnaissance de l'acte reste important

Et tuer à distance, c'est tuer quasiment par procuration : peu d'effort physique à fournir, pas de risque de te prendre un coup de boule, ni de devoir lutter contre le mec qui se vide de son sang sur toi, … C'est propre, presque sans risque. Tu presses, ça tombe.

À mon humble avis tu touches là le point essentiel : la psychologie. À ta description on doit pouvoir ajouter aussi la douleur, les armes à feu sont souvent moins douloureuses que beaucoup d'autres outils. Et renforcer l'instantanéité, pas besoin d'attendre le résultat il est souvent immédiat.

Enfin, concernant les usages terroristes et/ou tueurs de masse, il y a aussi la psychologie de l'impact sur ceux qui voient / constatent. Et le besoin de reconnaissance de l'acte.

Mais c'est bien l'efficacité de cette solution, et le fait que ces 'outils' n'aient été inventé que pour cela, tuer, qui donne réellement la problématique initiale. Même si cet aspect psychologique est important -et intéressant- ainsi que les cultures locales et leurs influences, il n'en reste pas moins qu'avant cet aspect, ces outils ne sont conçus que pour ça.

on peut noter que certains terroristes ont dépassés ce stade de l'arme à feu, par opportunisme, adaptation aux circonstances, et/ou facilité. Et ont fait tomber le côté 'spectacle' du résultat l'arme à feu : il est bien plus efficace de foncer sur une foule avec un camion. Mais le besoin de reconnaissance de l'acte reste important, donc un empoisonnement au roundup d'un réseau de distribution d'eau n'est pas prêt de se faire, et heureusement car ce n'est pas le chlore ajouté qui arrêtera le roundup.

Aucune idée si c'est l'état de coma dans lequel on se trouve, si c'est le cocktail de produits, ou si c'est un produit particulier. Moi aussi j'ai eu des pertes de mémoires après l'anésthésie générale. Je ne m'en suis pas apperçu tout de suite, ce que j'ai d'abord constaté c'est "plein de cases mémorielles libres", période où j'ai amassé plein de nouvelles connaissances comme un gamin de 8 ans ..
C'est plus tard que je me suis rendu compte qu'il me manquait beaucoup de souvenirs d'une part (films, livres, moment vécus pourtant marqueurs importants de certains instants / périodes) et d'autre part que j'avais du mal à retenir ce qu'on taggue comme des "noms propres" qui m'étaient nouveaux, si je ne les utilisais pas souvent.