Déjà apparament pas ceux qui lisent ce thread. Les explications de Pbpg sont très claires, mais un certain nombre de personne (dont toi) semblent confondre escalade de droit, changement de profil et passage en mode super-utilisateur.
Dans un monde ou les ACL et les containers sont en train de devenir la norme, je ne te cache pas que ca fait un peu peur.
Pour te donner une idée j'ai sur un de mes serveurs FreeBSD un utilisateur root qui n'a comme droit super user que celui de créer des backups avec préservation des ACL (et il ne peut même pas effacer ou modifier ses propres backups). Bien entendu le même utilisateur root qui se connecte différamment aura d'autres droits.
De même ces mêmes lecteurs de threads ne semblent pas voir l'intéret qu'il y a à connaitre l'utilisateur qui peut (par exemple) relancer un daemon ou un serveur. Or je peux te garantir que dans un domaine LDAP avec des groupes systèmes, des groupes domaines, des groupes locaux, des containers de sécurité et des règles de sécurité locale ca peut devenir loin d'être évident. Pourtant c'est utile pour le niveau 1 de savoir quel admin on apelle à 3h du matin pour relancer le serveur de mail.
[^] # Re: On se demande qui est l'idiot/enflure
Posté par Jerome Herman . En réponse au journal On connait un des brevets microsoftiens que linux viole. Évalué à 2.
Déjà apparament pas ceux qui lisent ce thread. Les explications de Pbpg sont très claires, mais un certain nombre de personne (dont toi) semblent confondre escalade de droit, changement de profil et passage en mode super-utilisateur.
Dans un monde ou les ACL et les containers sont en train de devenir la norme, je ne te cache pas que ca fait un peu peur.
Pour te donner une idée j'ai sur un de mes serveurs FreeBSD un utilisateur root qui n'a comme droit super user que celui de créer des backups avec préservation des ACL (et il ne peut même pas effacer ou modifier ses propres backups). Bien entendu le même utilisateur root qui se connecte différamment aura d'autres droits.
De même ces mêmes lecteurs de threads ne semblent pas voir l'intéret qu'il y a à connaitre l'utilisateur qui peut (par exemple) relancer un daemon ou un serveur. Or je peux te garantir que dans un domaine LDAP avec des groupes systèmes, des groupes domaines, des groupes locaux, des containers de sécurité et des règles de sécurité locale ca peut devenir loin d'être évident. Pourtant c'est utile pour le niveau 1 de savoir quel admin on apelle à 3h du matin pour relancer le serveur de mail.