05-03-2021, 14:29:36
N'importe quel barbu linux vous dira que sudo c'est très dangereux niveau sécu. (et donc que Ubuntu en le forçant crée plus de problèmes qu'il n'en résoud).
On va dire que lancer de l'interface graphique est fortement déconseillé en admin sous linux (pour un tas de bonnes raisons) et ça peut importe la distrib.
La tendance actuelle est de faire le max en espace utilisateur en donnant certains privilèges si besoin.
Ca pose évidement de vrais soucis niveau applicatif : si ces derniers sont trop vieux et n'ont pas intégré cette notion par exemple.
Le cas le plus probant est "apt" qui nécessite d'avoir des droits root pour installer des softs. (je crois que c'est dans les tuyaux de résoudre ça mais c'est pas gagné)
Sur certains distribs récentes (NixOS, Guix mais il doit y en avoir d'autres), tu peux installer des paquets via le compte "toto" et les logiciels installés ne seront pas visibles pour les autres utilisateurs.
En revanche, cet utilisateur peut également installer les paquets pour un groupe d'utilisateurs (si il appartient à ce groupe bien sur).
C'est un peu l'idéal vers lequel toutes les distribs vont/doivent tendre donc Primtux y compris.
Par exemple, pour le PrimtuxMenu, j'ai trouvé une solution de contournement' : pour éviter de faire des demandes de mdp à chaque install de logiciels est d'avoir un daemon qui tourne en root (et qui execute les apt install) et un protocole d'échange (de l'HTTP mais ça pourrait être d'autre trucs genre DBUS) avec mon dameon via l'interface (qui elle a juste les droits lié à l'utilisateur "prof").
Pour moi, CTParental devrait être rattaché au compte "prof" et ne devrait pas à avoir d'autre mdp à gérer.
@Phillippe : pour ton exemple dans les familles, l'attention sur la sécurité doit être clairement mis sur la connexion.
Si les parents veulent garder le contrôle : ils ne donnent pas leur mdp.
Si les enfants font certaines tâches en admin, ça nécessite de se connecter via l'aval d'un 'parent et idéalement que le parent les accompagne tout le long.
Si les enfants connaissent déjà le mdp "prof", je vois pas en quoi leur redemander va les bloquer en quoi que ce soit si vraiment ils sont en mode "jouer avec le feu".
@cyrille : je pense que tu serais moins frustré si tu faisais les choses dans l'ordre.
Tu proposes un soft, on en parle et on défini ensemble l'expression du besoin et après tu réalises.
Je peux comprendre l'effet grisant de partir direct sur le code mais en faisant ça tu te mets tout seul dans une situation inconfortable.
J'ai eu moi-même ce travers longtemps mais travaillant dans l'IT, j'ai du m'adapter.
Avec le recul, j'ai tendance à passer beaucoup plus de temps en pourparler, planification, architecture etc. Mais en appliquant ça j'ai beaucoup moins de code poubelle au final : je vais direct à l'essentiel.
On va dire que lancer de l'interface graphique est fortement déconseillé en admin sous linux (pour un tas de bonnes raisons) et ça peut importe la distrib.
La tendance actuelle est de faire le max en espace utilisateur en donnant certains privilèges si besoin.
Ca pose évidement de vrais soucis niveau applicatif : si ces derniers sont trop vieux et n'ont pas intégré cette notion par exemple.
Le cas le plus probant est "apt" qui nécessite d'avoir des droits root pour installer des softs. (je crois que c'est dans les tuyaux de résoudre ça mais c'est pas gagné)
Sur certains distribs récentes (NixOS, Guix mais il doit y en avoir d'autres), tu peux installer des paquets via le compte "toto" et les logiciels installés ne seront pas visibles pour les autres utilisateurs.
En revanche, cet utilisateur peut également installer les paquets pour un groupe d'utilisateurs (si il appartient à ce groupe bien sur).
C'est un peu l'idéal vers lequel toutes les distribs vont/doivent tendre donc Primtux y compris.
Par exemple, pour le PrimtuxMenu, j'ai trouvé une solution de contournement' : pour éviter de faire des demandes de mdp à chaque install de logiciels est d'avoir un daemon qui tourne en root (et qui execute les apt install) et un protocole d'échange (de l'HTTP mais ça pourrait être d'autre trucs genre DBUS) avec mon dameon via l'interface (qui elle a juste les droits lié à l'utilisateur "prof").
Pour moi, CTParental devrait être rattaché au compte "prof" et ne devrait pas à avoir d'autre mdp à gérer.
@Phillippe : pour ton exemple dans les familles, l'attention sur la sécurité doit être clairement mis sur la connexion.
Si les parents veulent garder le contrôle : ils ne donnent pas leur mdp.
Si les enfants font certaines tâches en admin, ça nécessite de se connecter via l'aval d'un 'parent et idéalement que le parent les accompagne tout le long.
Si les enfants connaissent déjà le mdp "prof", je vois pas en quoi leur redemander va les bloquer en quoi que ce soit si vraiment ils sont en mode "jouer avec le feu".
@cyrille : je pense que tu serais moins frustré si tu faisais les choses dans l'ordre.
Tu proposes un soft, on en parle et on défini ensemble l'expression du besoin et après tu réalises.
Je peux comprendre l'effet grisant de partir direct sur le code mais en faisant ça tu te mets tout seul dans une situation inconfortable.
J'ai eu moi-même ce travers longtemps mais travaillant dans l'IT, j'ai du m'adapter.
Avec le recul, j'ai tendance à passer beaucoup plus de temps en pourparler, planification, architecture etc. Mais en appliquant ça j'ai beaucoup moins de code poubelle au final : je vais direct à l'essentiel.