Ha ok, ca ne change rien:
https://serverfault.com/questions/506087/why-is-local-root-able-to-su-to-any-ldap-user
Godzil (./792) :Comme le dit flan, tu ne pourras pas accéder de cette façon aux dossiers distants si c'est fait proprement (avec PAM), parce qu'il y a besoin du mot de passe (qui permet d'obtenir un jeton d'authentification réseau valide) pour monter ces volumes.
Root local n'as pas moyen d'acceder a des partages NFS sans que le partage ne se fasse avec des droits speciaux.
Root local ne peux pas changer le mot de passe d'un compte distant.
Par contre root peux se faire passer pour un compte distant et la acceder a tous les fichiers.
D'ailleurs, root ne pourrait que prendre l'identité d'un compte qui existe localement (qui a un UID/GID local). Il ne peut, dans le cas d'un annuaire LDAP, le faire que si le compte LDAP s'est déjà connecté (et que ça a abouti à la création d'un UID quelque part dans le système), soit parce que l'UID est accessible en lecture pour le compte root ou le système. Dans le cas contraire, je pense qu'il y a un message d'erreur indiquant "no such uid". Idem pour une authentification avec Kerberos.Je ne suis pas sûr : pour moi, root va pouvoir prendre l'identité de n'importe quel utilisateur défini dans getent passwd (sachant que getent passwd prend un login et fournit un uid/gid en échange, en cherchant dans toutes les bases configurées : /etc/passwd, LDAP, NIS, …).
Flan > Il y a énormément de situations où le UID/GID n'existe que sur l'annuaire et pas localement (ce que tu appelles "de secours") - sauf pour root, évidemment, mais avoir un compte root dans l'annuaire LDAP est sujet à risques - mais il faut que les mécanismes de création de compte dans l'annuaire LDAP interdisent la création d'un compte avec l'uid root (je crois qu'il y a des cas documentés de pourrissage du système avec genre un Robert Oot, qui devient un compte "root", mais sans uid 0, ce qui perturbe le système).Oui, bien sûr : ce n'est qu'une possibilité, et c'est très risqué en local pour la base des uid/gid (il suffit d'avoir un uid/gid différent dans le LDAP et le /etc/passwd pour avoir des bugs « rigolos »).
flanker (./795) :Dans cette situation, getent fait une requête LDAP sur le serveur qui va retourner l'uidNumber. Faut-il que le système Unix en question soit configuré avec un utilisateur LDAP permettant de faire des requêtes qui retournent l'uidNumber (ou que l'uidNumber revienne avec une requête anonyme), ce qui n'est pas forcément le cas : tu peux très bien récupérer l'uidNumber à la négociation de la session par PAM, avec l'utilisateur seul qui soit en mesure de récupérer cet attribut dans l'annuaire. Du coup, dans ce cas-là, getent passwd ne renverra rien, mais un login fonctionnera. Et root, sauf s'il existe dans l'annuaire évidemment, ne pourra pas récupérer un uid pour devenir "quelqu'un d'autre du réseau).
Je ne suis pas sûr : pour moi, root va pouvoir prendre l'identité de n'importe quel utilisateur défini dans getent passwd (sachant que getent passwd prend un login et fournit un uid/gid en échange, en cherchant dans toutes les bases configurées : /etc/passwd, LDAP, NIS, …).
Bien sûr, on ne parle que de la fourniture d'identité par LDAP (via getent), pas la fourniture de mot de passe (même si les deux généralement stockés au même endroit dans LDAP, ça pourrait être deux LDAP différents).
Si l'utilisateur en question ne s'est pas connecté, root n'aura pas de credentials à voler et donc il ne pourra pas monter les partages réseau (par exemple son home) — à nouveau, sauf si le serveur de fichier n'est pas un gros trou de sécurité à lui tout seul.
Zerosquare (./802) :Tu établis ta vision en partant du fichier CSV, en considérant que c'est un fichier qui contient des données brutes et donc n'importe quel logiciel devrait le traduire en données brutes. Je n'ai pas le même avis. Excel est un tableur qui propose des fonctions et des macros. Il propose également d'importer un certain nombre de fichiers et de les considérer comme des tableurs, qui peuvent donc contenir des fonctions et des macros. En d'autres termes ça dépend si tu considères que l'interprétation doit être dictée par le fichier ou l'éditeur, pour moi c'est la deuxième option. Pour la même raison, si j'ouvre un ".txt" avec mon éditeur d'image je me retrouve avec un bitmap dans lequel les caractères ont été retranscris sous une forme visuelle. Pour autant je ne m'en étonne pas et je ne m'attendais pas à ce que parce que c'est un document texte il me l'ouvre comme un éditeur de texte.
Je n'ai pas la même vision. Pour moi, l'import CSV pour un tableur, c'est comme l'import TXT pour un traitement de texte : c'est fait pour importer des données brutes telles quelles (si on m'avait posé la question avant de lire l'article, j'aurais dit que les formules étaient importées en tant que texte).
Zerosquare (./802) :C'est exactement le cas : tu remarqueras dans mes captures que les boutons qui n'activent pas les fonctions sont ceux par défaut. Si ce que tu veux dire c'est "ça aurait du être planqué au 36-ième niveau d'un sous-menu caché" alors ça n'est pas ce que j'appelle de la sécurité.
Pour moi c'est une feature qui devrait être au minimum désactivée par défaut, parce qu'elle est dangereuse.