Si tu passes root avec su -, l'historique des commandes est également disponible.
kdevelop par rpm
Avec su - , l'historique à destination de root n'est disponible que pour root # , mais pas sous user ~
Normal puisque quand tu fait su - tu passes sous root... Je vois pas ouù est le problème.
Je crois qu'il veut juste dire que c'est plus pratique de ne pas passer en root pour consulter l'historique. Je ne le fais pas mais je le comprend.
Exactement zetoun
D'un autre côté, regarder les logs, c'est un truc d'admins, pas d'user. Même si sudo est très souple et à des avantages certains, je suis assez scéptique sur son utilisation à tout va... Je l'utilise très peu (4 personnes sur le même PC). Quand je dois mettre le nez dans les logs, je revêt mon costume d'admin, et je tape su -
C'est trop facile de faire une connerie quand on est débutant. Et c'est le cas de Mueza apparement.
SU - me paraît nettement plus approprié pour l'instant. Mais après tout, c'est Linux, on peut faire ce qu'on veut. :lol:
C'est trop facile de faire une connerie quand on est débutant. Et c'est le cas de Mueza apparement.
SU - me paraît nettement plus approprié pour l'instant. Mais après tout, c'est Linux, on peut faire ce qu'on veut. :lol:
En fait moi je suis seul sur mon PC, donc c'est plus pratique.
Et c'est aussi que sudo permet d'avoir un log de toutes les commandes entrées sous sudo
Et c'est aussi que sudo permet d'avoir un log de toutes les commandes entrées sous sudo
j'étais passé en root (sudo) à cause du denied
Root vs sudo, l'éternel débat.
Si sudo apporte une granularité plus fine par rapport à su en limitant le nombre de commandes que l'on peut exécuter en assumant l'identité d'un autre utilisateur, je suis pas d'accord avec son utilisation dans un desktop.
Supprimer le compte root pour donner tout les droits à un utilisateur via sudo fait perdre l'unique intérête de sudo: la granularité. Pire encore, sudo apporte de nouvelles failles, par exemple, par défaut, sudo est configuré pour permettre à l'utilisateur de ne pas à retaper son mot de passe pendant un certain temps. On justifie l'usage de sudo parce que certains utilisateurs indélicats se connectaient en root, mais au final, ces mêmes utilisateurs finissent par utiliser sudo pour tout et n'importe quoi. À force de se faire marteler que se connecter en root c'est mal, les utilisateurs débutants sont en général plus vigilants, là ou sudo leur donne une fausse impression de sécurité.
Sur le desktop, le modèle de sécurité de GNU/Linux est fondamentalement "défectueux", il ne répond pas à leurs besoins.
ConsoleKit et PolicyKit constituent l'avenir du bureau libre, dommage que la plupart des "grandes" distributions ne s'y intéressent pas vraiment.
Si sudo apporte une granularité plus fine par rapport à su en limitant le nombre de commandes que l'on peut exécuter en assumant l'identité d'un autre utilisateur, je suis pas d'accord avec son utilisation dans un desktop.
Supprimer le compte root pour donner tout les droits à un utilisateur via sudo fait perdre l'unique intérête de sudo: la granularité. Pire encore, sudo apporte de nouvelles failles, par exemple, par défaut, sudo est configuré pour permettre à l'utilisateur de ne pas à retaper son mot de passe pendant un certain temps. On justifie l'usage de sudo parce que certains utilisateurs indélicats se connectaient en root, mais au final, ces mêmes utilisateurs finissent par utiliser sudo pour tout et n'importe quoi. À force de se faire marteler que se connecter en root c'est mal, les utilisateurs débutants sont en général plus vigilants, là ou sudo leur donne une fausse impression de sécurité.
Sur le desktop, le modèle de sécurité de GNU/Linux est fondamentalement "défectueux", il ne répond pas à leurs besoins.
ConsoleKit et PolicyKit constituent l'avenir du bureau libre, dommage que la plupart des "grandes" distributions ne s'y intéressent pas vraiment.
@zetoun:
@Sat, +1 et tu m'énerves... Tu as l'art et la manière d'exprimer les choses d'une manière simple et concise. :hammer:
Une dernière question : pourquoi lancer kdevelop en root ?@Sat, +1 et tu m'énerves... Tu as l'art et la manière d'exprimer les choses d'une manière simple et concise. :hammer:
Justement, le cas de moueza illustre parfaitement l'intérêt de SELinux. Malgré les pouvoirs qu'il gagne grâce à sudo, il existe toujours des limitations à ce qu'il peut faire.
Dans un sens, c'est un peu comme si le système lui-même se protégeait.
Dans un sens, c'est un peu comme si le système lui-même se protégeait.
@Zetou... Tu vas un peu vite là... sudo n'est en aucun cas supérieur à su -
Pour la simple et bonne raison, c'est qu'au maximum il ne peut qu'être qu' égal à su - (je sais pas si je suis clair ?)
Quand à SElinux, il n'a d'intérêt que si il est bien configuré, surtout sur un poste perso. D'ailleurs, SELinux n'est configurable qu'en root, imagine le carnage si sudo était égal à root ?
(là encore je ne suis pas sur d'être clair. :-D )
Pour la simple et bonne raison, c'est qu'au maximum il ne peut qu'être qu' égal à su - (je sais pas si je suis clair ?)
Quand à SElinux, il n'a d'intérêt que si il est bien configuré, surtout sur un poste perso. D'ailleurs, SELinux n'est configurable qu'en root, imagine le carnage si sudo était égal à root ?
(là encore je ne suis pas sur d'être clair. :-D )
J'ai peut-être pas été trés clair non plus.😉
En aucun cas je considère que sudo est supérieur à su -. Je soulignais juste le fait que SELinux pouvait éviter aux sudoers de faire des bétises (si il est bien configuré, bien entendu:-))
En aucun cas je considère que sudo est supérieur à su -. Je soulignais juste le fait que SELinux pouvait éviter aux sudoers de faire des bétises (si il est bien configuré, bien entendu:-))
A priori PolicyKit fait partie de Fedora 8, le projet est indiqué comme 100% complete.Sat wrote:Sur le desktop, le modèle de sécurité de GNU/Linux est fondamentalement "défectueux", il ne répond pas à leurs besoins.
ConsoleKit et PolicyKit constituent l'avenir du bureau libre, dommage que la plupart des "grandes" distributions ne s'y intéressent pas vraiment.