Je suis hyper préssé par un truc qui a peut-être une explication simple :
Dans mon /etc/passwd (freebsd5.1R), j'ai des groupes qui contiennent des
users.
Quand je tape 'id user4', je ne vois pas *tous* les groupes dans lesquels
il est censé apparaître.
Est-ce une histoire de longueur de ligne ? (apparament pas, d'après le man)
Comment diagnostiquer ça ? En gros, quelle commande inverse de id existe
pour les groupes ?
Truc hyper étrange : - id user4 me donne une liste restreinte de groupes - pp usershow -P user4 me donne bien toute la liste
Y a t'il un fichier a recompiler (à la façon de login.conf ou passwd ?)
-- Nicolas Ecarnot
gregg
Nicolas Ecarnot wrote:
Bonjour,
Je suis hyper préssé par un truc qui a peut-être une explication simple : Dans mon /etc/passwd (freebsd5.1R), j'ai des groupes qui contiennent des users. Quand je tape 'id user4', je ne vois pas *tous* les groupes dans lesquels il est censé apparaître.
n'y aurait-il pas un alias défini quelquepart ? (du style alias id "id -gn")
Nicolas Ecarnot wrote:
Bonjour,
Je suis hyper préssé par un truc qui a peut-être une explication simple :
Dans mon /etc/passwd (freebsd5.1R), j'ai des groupes qui contiennent des
users.
Quand je tape 'id user4', je ne vois pas *tous* les groupes dans lesquels
il est censé apparaître.
n'y aurait-il pas un alias défini quelquepart ?
(du style alias id "id -gn")
Je suis hyper préssé par un truc qui a peut-être une explication simple : Dans mon /etc/passwd (freebsd5.1R), j'ai des groupes qui contiennent des users. Quand je tape 'id user4', je ne vois pas *tous* les groupes dans lesquels il est censé apparaître.
n'y aurait-il pas un alias défini quelquepart ? (du style alias id "id -gn")
Nicolas Ecarnot
gregg wrote in news:3ff96847$0$17136$:
Nicolas Ecarnot wrote:
Bonjour,
Je suis hyper préssé par un truc qui a peut-être une explication simple : Dans mon /etc/passwd (freebsd5.1R), j'ai des groupes qui contiennent des users. Quand je tape 'id user4', je ne vois pas *tous* les groupes dans lesquels il est censé apparaître.
n'y aurait-il pas un alias défini quelquepart ? (du style alias id "id -gn")
Non, pas d'alias en rapport avec les commandes pw... Je peux difficilement rebooter, et de toute façon, on n'est pas sous ouindoze...
-- Nicolas Ecarnot
gregg <greggory@netJUSTSAYNOcourrier.com> wrote in
news:3ff96847$0$17136$626a54ce@news.free.fr:
Nicolas Ecarnot wrote:
Bonjour,
Je suis hyper préssé par un truc qui a peut-être une explication
simple : Dans mon /etc/passwd (freebsd5.1R), j'ai des groupes qui
contiennent des users.
Quand je tape 'id user4', je ne vois pas *tous* les groupes dans
lesquels il est censé apparaître.
n'y aurait-il pas un alias défini quelquepart ?
(du style alias id "id -gn")
Non, pas d'alias en rapport avec les commandes pw...
Je peux difficilement rebooter, et de toute façon, on n'est pas sous
ouindoze...
Je suis hyper préssé par un truc qui a peut-être une explication simple : Dans mon /etc/passwd (freebsd5.1R), j'ai des groupes qui contiennent des users. Quand je tape 'id user4', je ne vois pas *tous* les groupes dans lesquels il est censé apparaître.
n'y aurait-il pas un alias défini quelquepart ? (du style alias id "id -gn")
Non, pas d'alias en rapport avec les commandes pw... Je peux difficilement rebooter, et de toute façon, on n'est pas sous ouindoze...
-- Nicolas Ecarnot
manu
Nicolas Ecarnot wrote:
Quand je tape 'id user4', je ne vois pas *tous* les groupes dans lesquels il est censé apparaître.
Y'en a combien? Sur la plupart des systèmes, la limite est assez basse: 16 groupes par utilisateur. Après ca fait des bugs étranges.
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Nicolas Ecarnot <nicolas.ecarnot@alussinan.org> wrote:
Quand je tape 'id user4', je ne vois pas *tous* les groupes dans lesquels
il est censé apparaître.
Y'en a combien? Sur la plupart des systèmes, la limite est assez basse:
16 groupes par utilisateur. Après ca fait des bugs étranges.
--
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu@netbsd.org
Quand je tape 'id user4', je ne vois pas *tous* les groupes dans lesquels il est censé apparaître.
Y'en a combien? Sur la plupart des systèmes, la limite est assez basse: 16 groupes par utilisateur. Après ca fait des bugs étranges.
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Nicolas Ecarnot
(Emmanuel Dreyfus) wrote in news:1g740v0.1az7ijznjju6uN%:
Y'en a combien? Sur la plupart des systèmes, la limite est assez basse: 16 groupes par utilisateur. Après ca fait des bugs étranges.
Oui, c'est bien 16. Bon je suis bien planté alors.
Un truc que j'ai du mal à comprendre quand à cette restriction : Pourquoi le nombre de groupes du système est quasiment infini tandis que le nombre de groupe par utilisateur est limité à 16 ? Le fait de disposer d'un grand nombre de groupes aurait plutôt tendance à permettre d'utiliser ces groupes pour les mêmes utilisateurs...
Je n'arrive pas à comprendre comment se gère par exemple un grand nombre de répertoires de projet, sur lesquels doivent travailler un grand nombre de personnes, mais dont les droits changent d'un projet à l'autre : Bien obligé d'utiliser un groupe par projet !?!
Comprends pô !
-- Nicolas Ecarnot
manu@netbsd.org (Emmanuel Dreyfus) wrote in
news:1g740v0.1az7ijznjju6uN%manu@netbsd.org:
Y'en a combien? Sur la plupart des systèmes, la limite est assez
basse: 16 groupes par utilisateur. Après ca fait des bugs étranges.
Oui, c'est bien 16.
Bon je suis bien planté alors.
Un truc que j'ai du mal à comprendre quand à cette restriction : Pourquoi
le nombre de groupes du système est quasiment infini tandis que le nombre
de groupe par utilisateur est limité à 16 ?
Le fait de disposer d'un grand nombre de groupes aurait plutôt tendance à
permettre d'utiliser ces groupes pour les mêmes utilisateurs...
Je n'arrive pas à comprendre comment se gère par exemple un grand nombre de
répertoires de projet, sur lesquels doivent travailler un grand nombre de
personnes, mais dont les droits changent d'un projet à l'autre : Bien
obligé d'utiliser un groupe par projet !?!
(Emmanuel Dreyfus) wrote in news:1g740v0.1az7ijznjju6uN%:
Y'en a combien? Sur la plupart des systèmes, la limite est assez basse: 16 groupes par utilisateur. Après ca fait des bugs étranges.
Oui, c'est bien 16. Bon je suis bien planté alors.
Un truc que j'ai du mal à comprendre quand à cette restriction : Pourquoi le nombre de groupes du système est quasiment infini tandis que le nombre de groupe par utilisateur est limité à 16 ? Le fait de disposer d'un grand nombre de groupes aurait plutôt tendance à permettre d'utiliser ces groupes pour les mêmes utilisateurs...
Je n'arrive pas à comprendre comment se gère par exemple un grand nombre de répertoires de projet, sur lesquels doivent travailler un grand nombre de personnes, mais dont les droits changent d'un projet à l'autre : Bien obligé d'utiliser un groupe par projet !?!
Comprends pô !
-- Nicolas Ecarnot
pornin
According to Nicolas Ecarnot :
Un truc que j'ai du mal à comprendre quand à cette restriction : Pourquoi le nombre de groupes du système est quasiment infini tandis que le nombre de groupe par utilisateur est limité à 16 ?
Vu du noyau, un groupe c'est un nombre (le GID, sur 16 ou 32 bits suivant les OS). Vu du côté utilisateur, le "groupe principal" d'un utilisateur est celui indiqué dans la base de données "passwd" (celle générée par pwd_mkdb à partir de /etc/master.passwd) et les autres sont référencés dans le /etc/group. Ces fichiers peuvent contenir un nombre quasi arbitraire de groupes (la taille du fichier, et la taille en bits d'un GID, sont les seules limites effectives).
Du temps d'Unix v7, chaque processus avait à tout moment un unique GID, utilisé par le noyau pour vérifier les droits d'accès aux fichier. Quand un processus voulait changer de GID, il appelait la commande newgrp, qui avait un bit S de root et faisait de la magie noire avec le noyau pour changer le GID du processus appelant. Cette commande utilisait le contenu de /etc/group pour savoir quels changements de groupe étaient valides.
Comme il est assez pénible (du point de vue programmation) d'appeler une commande externe et de gérer des changements de groupes, il a été rajouté dans 4.2BSD (vers 1983) des groupes supplémentaires. Chaque processus a toujours un GID principal (celui renvoyé par getgid()) mais possède aussi un ensemble de GID secondaires qui sont utilisés par le noyau pour les accès aux fichiers au cas où le GID principal ne permet pas un accès donné. Autrement dit, pour chaque processus, il y a dans le noyau une liste de GID, et pour chaque open(), le noyau essayera successivement ces GID jusqu'à ce qu'un de ces GID fonctionne. Cette liste de GID est mise en place via l'appel système setgroups(), normalement par le programme "login" ou son équivalent.
Ce système signifie que les groupes auxquels un utilisateur appartient prennent de la place mémoire dans le noyau, place qui est chère ; aussi, le nombre de ces groupes annexes est arbitrairement limité, en l'occurrence à 16 sous BSD.
On notera que le lien entre /etc/group et ces groupes annexes est fait par "login" (via la fonction initgroups(), normalement) et que rien ne l'impose, vu du noyau (le fichier /etc/group n'a aucune signification spéciale pour le noyau). Chaque processus peut potentiellement appartenir à tous les groupes possibles, dans la limite de 16 GID par processus.
Je n'arrive pas à comprendre comment se gère par exemple un grand nombre de répertoires de projet, sur lesquels doivent travailler un grand nombre de personnes, mais dont les droits changent d'un projet à l'autre : Bien obligé d'utiliser un groupe par projet !?!
La gestion de groupes est un des points noirs d'Unix. C'est pour cela que les ACL (Access Control Lists) ont été inventées. De mon point de vue, les choses se passent mieux, pour le travail en commun, si chaque utilisateur a sa propre copie locale des fichiers, et que le partage se fait via un système de versioning genre CVS. Ça permet de mettre en place des politiques d'accès plus fines, et par ailleurs le versioning est intéressant en soi.
--Thomas Pornin
According to Nicolas Ecarnot <nicolas.ecarnot@alussinan.org>:
Un truc que j'ai du mal à comprendre quand à cette restriction : Pourquoi
le nombre de groupes du système est quasiment infini tandis que le nombre
de groupe par utilisateur est limité à 16 ?
Vu du noyau, un groupe c'est un nombre (le GID, sur 16 ou 32 bits
suivant les OS). Vu du côté utilisateur, le "groupe principal" d'un
utilisateur est celui indiqué dans la base de données "passwd" (celle
générée par pwd_mkdb à partir de /etc/master.passwd) et les autres sont
référencés dans le /etc/group. Ces fichiers peuvent contenir un nombre
quasi arbitraire de groupes (la taille du fichier, et la taille en bits
d'un GID, sont les seules limites effectives).
Du temps d'Unix v7, chaque processus avait à tout moment un unique GID,
utilisé par le noyau pour vérifier les droits d'accès aux fichier. Quand
un processus voulait changer de GID, il appelait la commande newgrp,
qui avait un bit S de root et faisait de la magie noire avec le noyau
pour changer le GID du processus appelant. Cette commande utilisait le
contenu de /etc/group pour savoir quels changements de groupe étaient
valides.
Comme il est assez pénible (du point de vue programmation) d'appeler
une commande externe et de gérer des changements de groupes, il a été
rajouté dans 4.2BSD (vers 1983) des groupes supplémentaires. Chaque
processus a toujours un GID principal (celui renvoyé par getgid())
mais possède aussi un ensemble de GID secondaires qui sont utilisés
par le noyau pour les accès aux fichiers au cas où le GID principal ne
permet pas un accès donné. Autrement dit, pour chaque processus, il
y a dans le noyau une liste de GID, et pour chaque open(), le noyau
essayera successivement ces GID jusqu'à ce qu'un de ces GID fonctionne.
Cette liste de GID est mise en place via l'appel système setgroups(),
normalement par le programme "login" ou son équivalent.
Ce système signifie que les groupes auxquels un utilisateur appartient
prennent de la place mémoire dans le noyau, place qui est chère ;
aussi, le nombre de ces groupes annexes est arbitrairement limité, en
l'occurrence à 16 sous BSD.
On notera que le lien entre /etc/group et ces groupes annexes est fait
par "login" (via la fonction initgroups(), normalement) et que rien ne
l'impose, vu du noyau (le fichier /etc/group n'a aucune signification
spéciale pour le noyau). Chaque processus peut potentiellement
appartenir à tous les groupes possibles, dans la limite de 16 GID par
processus.
Je n'arrive pas à comprendre comment se gère par exemple un grand
nombre de répertoires de projet, sur lesquels doivent travailler un
grand nombre de personnes, mais dont les droits changent d'un projet à
l'autre : Bien obligé d'utiliser un groupe par projet !?!
La gestion de groupes est un des points noirs d'Unix. C'est pour cela
que les ACL (Access Control Lists) ont été inventées. De mon point de
vue, les choses se passent mieux, pour le travail en commun, si chaque
utilisateur a sa propre copie locale des fichiers, et que le partage
se fait via un système de versioning genre CVS. Ça permet de mettre en
place des politiques d'accès plus fines, et par ailleurs le versioning
est intéressant en soi.
Un truc que j'ai du mal à comprendre quand à cette restriction : Pourquoi le nombre de groupes du système est quasiment infini tandis que le nombre de groupe par utilisateur est limité à 16 ?
Vu du noyau, un groupe c'est un nombre (le GID, sur 16 ou 32 bits suivant les OS). Vu du côté utilisateur, le "groupe principal" d'un utilisateur est celui indiqué dans la base de données "passwd" (celle générée par pwd_mkdb à partir de /etc/master.passwd) et les autres sont référencés dans le /etc/group. Ces fichiers peuvent contenir un nombre quasi arbitraire de groupes (la taille du fichier, et la taille en bits d'un GID, sont les seules limites effectives).
Du temps d'Unix v7, chaque processus avait à tout moment un unique GID, utilisé par le noyau pour vérifier les droits d'accès aux fichier. Quand un processus voulait changer de GID, il appelait la commande newgrp, qui avait un bit S de root et faisait de la magie noire avec le noyau pour changer le GID du processus appelant. Cette commande utilisait le contenu de /etc/group pour savoir quels changements de groupe étaient valides.
Comme il est assez pénible (du point de vue programmation) d'appeler une commande externe et de gérer des changements de groupes, il a été rajouté dans 4.2BSD (vers 1983) des groupes supplémentaires. Chaque processus a toujours un GID principal (celui renvoyé par getgid()) mais possède aussi un ensemble de GID secondaires qui sont utilisés par le noyau pour les accès aux fichiers au cas où le GID principal ne permet pas un accès donné. Autrement dit, pour chaque processus, il y a dans le noyau une liste de GID, et pour chaque open(), le noyau essayera successivement ces GID jusqu'à ce qu'un de ces GID fonctionne. Cette liste de GID est mise en place via l'appel système setgroups(), normalement par le programme "login" ou son équivalent.
Ce système signifie que les groupes auxquels un utilisateur appartient prennent de la place mémoire dans le noyau, place qui est chère ; aussi, le nombre de ces groupes annexes est arbitrairement limité, en l'occurrence à 16 sous BSD.
On notera que le lien entre /etc/group et ces groupes annexes est fait par "login" (via la fonction initgroups(), normalement) et que rien ne l'impose, vu du noyau (le fichier /etc/group n'a aucune signification spéciale pour le noyau). Chaque processus peut potentiellement appartenir à tous les groupes possibles, dans la limite de 16 GID par processus.
Je n'arrive pas à comprendre comment se gère par exemple un grand nombre de répertoires de projet, sur lesquels doivent travailler un grand nombre de personnes, mais dont les droits changent d'un projet à l'autre : Bien obligé d'utiliser un groupe par projet !?!
La gestion de groupes est un des points noirs d'Unix. C'est pour cela que les ACL (Access Control Lists) ont été inventées. De mon point de vue, les choses se passent mieux, pour le travail en commun, si chaque utilisateur a sa propre copie locale des fichiers, et que le partage se fait via un système de versioning genre CVS. Ça permet de mettre en place des politiques d'accès plus fines, et par ailleurs le versioning est intéressant en soi.
--Thomas Pornin
Nicolas Ecarnot
(Thomas Pornin) wrote in news:bte14f$1osi$:
Merci infiniment pour ces explications brillantes qui m'éclairent tant d'un point de vue historique que technique. Je comprends désormais mieux pourquoi cette fonctionnalité des groupes supplémentaires n'est absolument pas faite pour la gestion du côté utilisateur. Je suis en train d'utiliser les ACL qui vont un peu m'aider, mais je sens que le pas en avant est timide.
Concernant CVS, on commence aussi à s'en servir, et pas uniquement chez les codeurs, mais la démarche va être longue.
Encore un grand merci.
-- Nicolas Ecarnot
pornin@nerim.net (Thomas Pornin) wrote in
news:bte14f$1osi$1@biggoron.nerim.net:
Merci infiniment pour ces explications brillantes qui m'éclairent tant d'un
point de vue historique que technique.
Je comprends désormais mieux pourquoi cette fonctionnalité des groupes
supplémentaires n'est absolument pas faite pour la gestion du côté
utilisateur.
Je suis en train d'utiliser les ACL qui vont un peu m'aider, mais je sens
que le pas en avant est timide.
Concernant CVS, on commence aussi à s'en servir, et pas uniquement chez les
codeurs, mais la démarche va être longue.
Merci infiniment pour ces explications brillantes qui m'éclairent tant d'un point de vue historique que technique. Je comprends désormais mieux pourquoi cette fonctionnalité des groupes supplémentaires n'est absolument pas faite pour la gestion du côté utilisateur. Je suis en train d'utiliser les ACL qui vont un peu m'aider, mais je sens que le pas en avant est timide.
Concernant CVS, on commence aussi à s'en servir, et pas uniquement chez les codeurs, mais la démarche va être longue.
Encore un grand merci.
-- Nicolas Ecarnot
manu
Nicolas Ecarnot wrote:
Concernant CVS, on commence aussi à s'en servir, et pas uniquement chez les codeurs, mais la démarche va être longue.
C'est très utile CVS, le versionning c'est très pratique, on peut taguer les sources à un moment donné pour pouvoir retrouver cet etat là plus tard, et ca facilite pas mal les backups.
-- Emmanuel Dreyfus A lire: 240 pages en français sur l'administration UNIX avec BSD http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Nicolas Ecarnot <nicolas.ecarnot@alussinan.org> wrote:
Concernant CVS, on commence aussi à s'en servir, et pas uniquement chez les
codeurs, mais la démarche va être longue.
C'est très utile CVS, le versionning c'est très pratique, on peut taguer
les sources à un moment donné pour pouvoir retrouver cet etat là plus
tard, et ca facilite pas mal les backups.
--
Emmanuel Dreyfus
A lire: 240 pages en français sur l'administration UNIX avec BSD
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu@netbsd.org
Concernant CVS, on commence aussi à s'en servir, et pas uniquement chez les codeurs, mais la démarche va être longue.
C'est très utile CVS, le versionning c'est très pratique, on peut taguer les sources à un moment donné pour pouvoir retrouver cet etat là plus tard, et ca facilite pas mal les backups.
-- Emmanuel Dreyfus A lire: 240 pages en français sur l'administration UNIX avec BSD http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu
Xavier wrote:
C'est très utile CVS, le versionning c'est très pratique, on peut taguer les sources à un moment donné pour pouvoir retrouver cet etat là plus tard, et ca facilite pas mal les backups. Et la secrétaire avec Word, elle fait comment ?
J'ai pas dit que c'etait pour elle.
Je ne vais pas une seconde immaginer une implémentation de CVS integrée dans Word, ils seraient capable de le rendre in-interoperable avec le reste du monde.
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Xavier <xavier@groumpf.org> wrote:
C'est très utile CVS, le versionning c'est très pratique, on peut taguer
les sources à un moment donné pour pouvoir retrouver cet etat là plus
tard, et ca facilite pas mal les backups.
Et la secrétaire avec Word, elle fait comment ?
J'ai pas dit que c'etait pour elle.
Je ne vais pas une seconde immaginer une implémentation de CVS integrée
dans Word, ils seraient capable de le rendre in-interoperable avec le
reste du monde.
--
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu@netbsd.org
C'est très utile CVS, le versionning c'est très pratique, on peut taguer les sources à un moment donné pour pouvoir retrouver cet etat là plus tard, et ca facilite pas mal les backups. Et la secrétaire avec Word, elle fait comment ?
J'ai pas dit que c'etait pour elle.
Je ne vais pas une seconde immaginer une implémentation de CVS integrée dans Word, ils seraient capable de le rendre in-interoperable avec le reste du monde.
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
